2.3.1. Run:Run
The Run page allows the user to run and monitor the simulation file as it is represented in the input editor, and/or to create multiple runs using the input file as the basic input by overriding some parameters.

2.3.1.1. Ribbon
Label |
Shortcut |
Description |
---|---|---|
|
Ins |
Add a new simulation/input or group Groups allow better organisation of runs in the tree |
|
Del |
Delete the selected runs or spawned jobs |
|
Ctrl-D |
Clone/Duplicate the selected runs |
|
Loop on the selected runs.
Allows the user to create clones of runs by
looping on a user defined variable ( E.g. Imagine you want to run 9 simulations with varying energy from 10 to 100MeV
Tip: You can loop on looped runs to create 2D scans. etc. |
|
|
Ctrl-Up |
Move upwards the selected runs |
|
Ctrl-Dn |
Move downwards the selected runs |
|
F2,Ctrl-E |
Rename the selected run |
|
Export/Save selected inputs to files (same as using the null queue) |
Label |
Shortcut |
Description |
---|---|---|
|
The drop down box allows you to select the submit queue. You can define your own queues in the Configuration dialog Preferences} |
|
|
Find the last random number seed file available for the highlighted run and set it to the “Previous” spin box |
|
|
Ctrl-t |
flair will try to find in which directory the run takes place in order to monitor the progress of the run. Attach is done automatically when submitting a job. |
Prev |
Select the previous(last) cycle in case you want to continue a run Note
|
|
No |
Number of cycles to be performed |
|
To |
Last cycle to run (To = Prev + No) automatically updated |
Label |
Shortcut |
Description |
---|---|---|
|
Delete all FLUKA generated files for the selected run. Its a good habit to clean before starting a new run. |
|
|
Creates a |
|
|
Creates a |
|
|
Issues a kill -SIGHUP command to the running process. If the user is using a batch system he has to substitute the kill command with the appropriate program Warning killing the fluka run, no file will be saved and all results collected up to this point will be lost |
|
|
Ctrl-R |
Progress information is displayed at constant time intervals (~30 sec) defined the preferences dialog f4}. The refresh button will force the update of the progress information when pressed. |
|
Ctrl-Enter |
Submits a run using the submit command defined in preferences dialog f4}. |
2.3.1.2. Fields
Label |
Description |
---|---|
Title |
Title of the run |
Primaries |
Override the number of primaries to execute |
Rnd |
Random number seed. |
Time |
Time limit of run |
Mode |
Select simulation mode default is as the input was created else can be any of FLUKA, Moira, MCNP, PHITS,… |
Threads |
Number of threads to be used for this run (Moira) |
Exe |
Either select one of the default executables for the current mode or any user created executable file |
Default Defines |
Reset to the default |
Defines |
Preprocessor defines (enable/disable) and change the value. Leaving empty the value it will inherit the one from the master input
|
Progress |
Shows the progress of the run by peaking information from the fluka output file during runtime. |
2.3.1.3. Attaching process and progress monitoring
Attaching to process
flair is agnostic on where the run takes place (especially in “cluster”
environments), therefore it tries to find a possible running folder and output
files based on filenames and time-stamps, in order to monitor the progress of
the run. Flair is trying to peek the run information only by looking the status
of the output files. It doesn’t make use of the system process information. This
way it increases portability across different platforms, and batch systems (see
the qfluka
example for a substitution of the submit command). The default
behaviour of FLUKA is to report the status of the run a few times during the
whole run. There in very long runs flair could have difficulties in peeking the
correct information. You could force more verbose output in FLUKA with the
START
card.
Flair will be able to monitor the status only if the run takes place on the same directory. The drawback of this method is that takes some time to attach, and if many runs takes place at the same directory with the same name (highly not recommended) flair will prompt the user to select the current run to attach.
The information will be refreshed every half a minute (defined in the Preferences). During the execution the “Status” will change, initially to Waiting to attach, followed by Running and finally in Finished OK. The program is running decoupled from the flair editor, therefore if you click save on the project and exit the program. The next time you will open the program, flair will try to attach and display the current run status.
Status
- A run can have on of the following status
- Not Running:
not running of flair is not aware of any run
- Waiting to attach:
after submission or clicking the
Attach button, when flair is searching for possible output files to identify the run
- Running:
flair detected possible running output files which are still incomplete since the run takes place (or crashed)
- Finished OK:
if all output files have completed successfully
- Finished with ERRORS:
if there was a crash detected
- Finished interrupted:
if the user has interrupted Stopped the run
- * TIMED-OUT *:
if the output files are inactive after few minutes
Warning
if you don’t save the project after the run the program will not know that
there was a simulation being executed, and it will not try to attached to it.
To force to attach click on the Attach button.