[ISSUE] Namelist ordering requirements clarification

[ken-lauer]

Namelist ordering requirements

There are a variety of rules about namelist ordering, some of which can be determined from the manual. This is my current understanding of those requirements:

1. &setup must be the first in the namelists
2. &setup must come before &alter_setup (of course)
3. &profile_const, &profile_gauss, &profile_step, &profile_polynom, &profile_file all must come before any references to them (via their label)
   • &profile* must come before &beam if it contains references to the profile
   • &profile* must come before &field if it contains references to the profile
4. &sequence_const, &sequence_polynom, &sequence_power, &sequence_random all must come before any references to them (via their label)
   • &sequence* must come before &lattice if it has references to the sequence
5. &time must come before &beam
6. &time must come before &importbeam
7. &time must come before &importfield
8. &write should be near the end
9. &track should be near the end

Usage count

Some namelists must only be used once, whereas others can be used multiple times:

1. Single-use
   • &setup
2. Multi-use
   • &lattice
   • &field

User-reported errors

A LUME-Genesis user provided failure cases with the following:

1. &beam before &time causes a crash (libc++abi: terminating due to uncaught exception of type std::out_of_range: vector)
   • This is at least somewhat expected as the manual says &time must come before &beam
2. &lattice (with zmatch) in the wrong spot resulted in different and non-matching/incorrect results
   • Non-matching ordering: setup, time, profile_gauss, beam, lattice, track, and then write
   • Matching ordering: setup, lattice, time, profile_gauss, beam, field, track, and write
   • With a bit more testing, it appears that this is the requirement: &lattice must come before &beam - is this in all scenarios?

Overall question / thought

Could we come up with a full list of all the known requirements in this issue?
Maybe then we could determine a foolproof sort order of namelists - if it's even possible.
At the very least, we can add a documentation section about it.

I'd set up LUME-Genesis to make this a bit more user-friendly - either telling the user what's wrong with their ordering or perhaps helping them fix it.

[svenreiche]

Hi Ken,

I am working on it.
In what format do you want it: Flow-chart? or for each namelist, the prerequisits?

[ken-lauer]

Great, thanks Sven!

I think namelist prerequisites may be a good way of structuring it. We could then generate a flow chart from that information, if desirable.

[svenreiche]

Geensis-Dependence.pdf

Hi Kevin,
I made a flow diagram with all the dependencies. It is quite a mess and I hope you can figure it out.
While making it I found some inconsistencies and improvement. Not sure if we can make a back compatibility but I would try to chance the following:

1. Exclude the lattice parsing from the setup namelist. It can be done by just piping out lattice file and beamline as a string and feed the lattice element with it as default values.
2. Lattice element does the actually parsing of the lattice (beside the matching). It should become mandatory (but could be done before the track command if the lattice element is not initialized)
3. That way any sequences can be defined after the setup namelist (It is currently a very ugly feature that in the case that one wants to use sequences to taper etc they have to come first.
4. All stuff in alter_setup, where a new beamline is parsed or related to the lattice should also be moved into the lattice element
5. alter_setup will do only the up and down conversion then or any other change in the controls parameters (flags for input and output should be here as well).
6. a dedicated diagnostics namelist would be also good to move some not-so-intuitive part from setup namelist