Decisions

1. There will not be types for chains and patterns, just instances. Init contexts will cover the use case to create chains or patterns from templates.
2. A chain can only have one level of subchains, i.e. a chain in a chain in a chain will result in an exception.
3. Only patterns, not chains, may be used to send settings to devices (i.e. perform a "drive"). But, in order to be able to calculate settings for template chains, there has to be a stand-alone version of a chain, which will allow a trim to be performed.
   1. A chain that is not scheduled in a pattern is a stand-alone chain. Consequently, a chain which is scheduled in a pattern is not stand-alone, but just a chain.
   2. It shall be possible to persist stand-alone chains independently of any pattern it may later be put in (in contrast to non-standalone cycles and beam processes, which cannot be persisted independently from their stand-alone super cycles or cycles).
   3. Stand-alone chains may not become resident and may not be used to perform a drive. To become resident, they need to be contained in a pattern.
4. Chains may only contain (drivable) beam processes and / or other chains. Patterns may only contain chains (decision not final? beam-out beam processes?).
5. The same beam process may not be scheduled in multiple chains, nor may it be scheduled multiple times within the same chain. But to enable reuse and avoid unnecessary duplications, the same chain may be scheduled multiple times within the same chain or pattern. This means that a chain may reoccur as the same instance with the same pattern as the parent and / or as a subchain of another chain (but not as a subchain of the same chain, because recursive scheduling would create a loop). On the other hand, multiple patterns or chains may not contain the same chain, i.e. chains that are supposed to occur in more than one pattern or chain are to be copied.
6. When putting together chains and patterns, the application concerned (which is probably ParamModi) shall adhere to the following procedures:
   1. When putting stand-alone beam processes ("init beam processes") into stand-alone chains ("template chains"), these beam processes are to be copied.
   2. When putting other stand-alone chains ("sub-chains") into stand-alone chains ("template chains"), these sub-chains are to be copied, including their beam processes.
   3. When putting stand-alone chains ("template chains") into patterns, these template chains are to be copied, including their beam processes, sub-chains and the sub-chains' beam processes.
7. When deleting chains and patterns, the context itself and all of the scheduled contexts (including chains, sub-chains and beam processes) are deleted.

Database SQL

/common/home/bel/rmueller/lnx/dev_kepler/ws_release/lsa-db-scripts/2014/pattern_implementation.sql

Here is a PDF of the conecpt: PatternDatabaseDiagram.pdf

DB TODO: prevent scheduling the type or instance in itself

DB TODO: prevent to schedule a BPC, for which its scheduling is not yet defined (evt. BPC FK not pointing to BPC table but to BPC Scheduling table. TBD. Same problem for types.)

lsa-core(-gsi)

Prepared GSI variants GSIContextFinder /Persister and GSITypeFinder /Persister, using these instead of the common ones. Development of Pattern specific method will take place in these Finders/Persisters.

lsa-domain-commons: DAGGraphUtils, DAGGraphVertex, DAGGraphVertexImpl as base for the scheduling graph (will eventually undergo refactoring by Hanno, once he uses it for the particleTransferGraphs)

lsa-domain-settings: added RelativeTypeSchedulingItem + Impl as graph node for the scheduling

TODO: implement delete methods (for types, check, if instances exist)

Open points

• To be discussed with David / FAIRDV-Team: What are the use-cases for scheduling a context relative to the end of another context? Alternatively, would it be possible to schedule it to the beginning of the following context instead? To be discussed again with Jutta: How do you define the following context of some context then?
• is_explicit - put to beamprocess & beamproductionchain interface? or context? but definitely to interface! - add in the BeamProcessType, BeamProductionChainType interfaces
• creator_name - is not persisted at the moment? why? what is the purpose? - To be checked by Greg/Przemek
• discuss the handling of discrete BeamProcesses in the context of Patterns with David. Can we get rid of them, or are they still needed?

Other stuff

INCA-2839: Add columns POSITION and SORT_ORDER to the table DEVICES

DB: Maciej added it on the dev-db

Java: I did the Java implementation and Tests and I am ready to commit (small change in Device, DeviceFinderImpl, DevicePersistorImpl)

open: first Pro-DB, then Java-commit. From my side it can be done any time. When?

Due: ASAP Maciej and Chris are back on the 1st September so the DB change can be done that week, and Jutta can commit just afterwards. Release will be done the week after.

INCA-3043: Add column PARTICLE_TRANSFER_TYPE to the table PARTICLE_TRANSFERS

DB: Maciej applied it on dev.

Open: Apply on PRO, any time.

(Java side is long done since weeks, does not depend on DB change)

Due: next weeks Maciej and Chris are back on the 1st September so the DB change can be done that week

INCA-2843: Add new column to describe the ordering of particle transfers

DB: Maciej applied it on dev.

Open: Apply on PRO, not urgent, but can be any time.

Java: implementation to be done whenever this topic fits in to the list of tasks (Hanno). Not too urgent but until end of this year/beginning of next.

Due: next week/month Maciej and Chris are back on the 1st September so the DB change can be done that week. Hanno will Check with Roman when this could be put into accsoft-commons-domain: Accelerator.getParticleTransers() (should return OrderedSet?)

=> I want to discuss about app-generation: I introduced the drop down for BPTypeForm for the creation of BeamProcess Types in app-generation. Shall it always be non-visible for CERN (leads to BeamProcessTypeForm.UNDEFINED) and is it ok to show it only, when a system property is set?

Greg would explain SPS/LHC people this option and how to set it.

Or would you also want to show it? Is it ok this way?

Due: I would like to finish discussion so we could have it for our october release. Implementation is small+quick and almost done, just some discussion/clarification needed.

Closed points

• is_hidden - is it still in use at CERN? or replaced by CONTEXT_CATEGORIES? - Can be removed (replaced by context category)
• beam-in before beam-out - Hanno has implemented that

• BeamProcessTypeForm. We talked about it several times. I started implementing it in my CERN workspace and it is nearly finished. Greg will check with SPS/LHC how this could be called and what "forms" would be needed. If added to the API, GUI should support it. Jutta will do the implementation

  • new Attribute to Beamprocesstype, appropriate Enum and TABLE for storing BP Type Forms as foreign keys.

  • Should I open an issue for it, phrase what I already implemented and you check it?

  • Greg wanted to discuss about a nicer name? (but we could discuss inside the issue then)

  • Implemented. Was finally called BeamProcessTypePurpose.

Obsolete

Added BeamProductionChainType /TypeImpl PatternType /TypeImpl - Removed again (see decision 1)

lsa-client-gsi and lsa-core-gsi/client: added method saveContextType(ContextType type) to be able to create the new types programatically (see decision 1)

-- RaphaelMueller - 21 Aug 2014
-- JuttaFitzek - 21 Aug 2014