0 padding in gfile name

[plasmapotential]

when reading geqdsk, MAFOT does not 0 pad shot number. It does, however, 0 pad timestep. This happens at line 361 in efit_class.hxx. I have added the patch into the heatBranch branch, lines 362-363

proposed patch:
add the following line at line 362 in efit_class.hxx:
for(i=1;i<=(5+i)-int(ShotNr.len());i++) ShotNr.insert('0'); //insert zeros until ShotNr has a length of 6

[plasmapotential]

I have been running more and more cases that require sub-ms time precision, and as such the current version of MAFOT geqdsk naming does not seem to suffice, as it only allows ms level precision. For an example GEQDSK for shot 1 timestep 10 [us], the MAFOT GEQDSK naming would be g000001.00000.

In HEAT, I recently changed the time control so that it can handle any level of precision in time (ie it can span the entire spectrum of timescales, from microseconds to thousands of seconds). This is achieved by making no assumptions about the number of significant figures in the GEQDSK name. Additionally, I am now using an underscore "_" instead of a period, ".", to separate shot from time in the name, to accommodate decimal timesteps. Below are some examples:

• geqdsk_kappa165 will be assigned shot 1 time 1
• g204118.01004 will be assigned shot 1 time 1
• g204118_01004 will be assigned shot 204118 time 1004 [s]
• g111_0.000010 will be assigned shot 111 time 10 [us]

I have integrated this into MAFOT by changing the way shot and time are read and handled. They now remain LA_STRINGS instead of being converted. This happens in commit #0263389 in heatBranch

In that commit, I use if defined statements so that only HEAT programs are affected.

Would be good to eventually do a pull request of the heatBranch into main. to be discussed.