- 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.
- A chain can only have one level of subchains, i.e. a chain in a chain in a chain will result in an exception.
- 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.
- 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.
- 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).
- 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.
- Chains may only contain (drivable) beam processes and / or other chains. Patterns may only contain chains (decision not final? beam-out beam processes?).
- 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.
- When putting together chains and patterns, the application concerned (which is probably ParamModi) shall adhere to the following procedures:
- When putting stand-alone beam processes ("init beam processes") into stand-alone chains ("template chains"), these beam processes are to be copied.
- 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.
- 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.
- When deleting chains and patterns, the context itself and all of the scheduled contexts (including chains, sub-chains and beam processes) are deleted.
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.)
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.
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)
- 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?
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
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.
/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)
- 21 Aug 2014
- 21 Aug 2014