Validation of Corsika config files

[Voutsi]

I created the corsika branch and added an input card I used to make a testing of the production for protons.
There are a number of points I would like to clarify for corsika generation:

• Which corsika version to use (I currently run with 7.7)
• Which atmospheric data file to use? Do we keep atmprof_ecmwf_north_winter_fixed.dat
• List of files
  • Nucleon - nucleus x-section NUCNUCCS
  • EM interactions EGSDAT6_3.
  • Low E hadrons - nucleus collisions UrQMD-1.3.1-xs.dat
  • sectnu-II-04 for nucleus-nucleus xsections
  • qgsdat-II-04 HE hadronic interactions
• Magnetic field
  • I updated the magnetic field to today's values for La Palma. Do we want some more characteristic date?
  • ARRANG : I see it equals azimuth in some input cards I parsed through. Should it rather correspond to the angle of the array x-direction with the magnetic north?
• data storage tree: A directory per grid point, where we store all corsika jobs launched with the same Zd,Az ?

[jsitarek]

@Voutsi, about the magnetic field, note that it also depends on the height a.s.l., what height have you used?

[Voutsi]

@jsitarek , 2199m.
I used this calculator:
https://www.ngdc.noaa.gov/geomag/calculators/magcalc.shtml#igrfwmm

[jsitarek]

I'm not sure how it was done in the previous CTA production, but at least in MAGIC the (really old) values that we are using is not at the ground level, but at the height where the typical shower maximum happens, I do not remember which exactly value was used, but something of the order of 10 km. a.s.l.. The difference will not be large, but if we are already updating things, I would suggest to use a value at ~10 km

[moralejo]

Hi @Voutsi for most of the things you mention we should not make any change, right?

As for the B-field date let's go for some round value.

ARRANG sets the angle between geographic coordinates (the telescopes' ones) and "magnetic" (Corsika's) coordinates, so the angle must be the magnetic declination for whatever B-field date we choose. Mind the sign (check the earlier production settings)

data storage tree: I agree with your proposal.

[maxnoe]

I created the corsika branch

Why do we use different branches for the different programs? Wouldn't it be much easier to just have them in different directories? Then the current complete configuration could be seen on the main branch. With the branches, I'd had to checkout two or three branches in parallel.

[Voutsi]

The idea is to have independent versioning for the corsika and simtel, since we might run simtel several times on the same corsika files.

[mexanick]

moreover, when we decide on each configuration, it must be tagged (so only tags are used in production, not the branches, which are mutable)

[maxnoe]

Yes, sure. But then you'd use tags to different branches that don't have a shared history (other maybe than the first commit?).

Moreover, if you do related changes, they cannot be done in the same commit.

What you propose here is a pretty strong deviation from how git is normally used (explicitly creating unrelated branches). And I don't really see why the two reasons you gave warrant that.

[mexanick]

Well, the main reason is: corsika simulates showers, sim_telarray simulates their interaction with telescope. Thus, I don't see why they should be shared. Yes, certain parameters are somewhat mutually dependent, but sim_telarray has many more parameters. The reason why two branches would be in the same repo is simply to have one repo (I initially proposed to have actually two repositories, but was advised to have one). Having copied corsika configuration for different sim_telarray tags could be an option, but IMHO it is about the same level disadvantages as the ones you've listed above.

[mexanick]

and speaking of git usage: well, here it is used as a versioned DB... not the original use case, but why not, if it can work pretty well? ;)