Fort44 parser for pre 2007 Eirene fort.44 file versions #40
Conversation
|
This looks OK to me. Which of these versions have you been able to test with existing output files? It would be good to know which ones we've verified and which ones we're assuming will work based on b2plot. |
|
Also, @Mateasek do you have any thoughts on this PR, or additional file versions to test? |
I've tested only 20081111, all other versions are assumed to work based on the code from converter ( |
|
I can test 20170328 and 20180323 versions. I will try to look at the PR this evening. |
OK. I've found the following versions on the UKAEA filesystem which we can also check: 961228, 20000727, 20070912, 20080706. There may be more on other systems. Also, can you check whether it's 20070912 or 20071209? The PR includes the latter, but the fort.44 files I'm seeing at UKAEA are the former. |
It's 20071209. If fort.44 version is less than 20071209, |
|
I looked into the fort.44 file version 20180323, which already has the headers @jacklovell pointed out. I'm bit behind in the fort.44 knowledge so please correct me if I am wrong or if I am stating something obvious. In the file header it gives (observed from the fort44_2017 file) number of columns/rows 96 and 36 and that there are 2 atoms, 1 molecule and 1 ion in the simulation. All the 18 blocks being read by the parser have in headers 3456 or 6912, which corresponds to 96 * 36 * n, where n is 1 or 2. If n is 1, then I guess the block contains only information connected to a single species or a superposition for more species. Doesn't this mean the files with such headers are self-described as @jacklovell says and we can at least safely parse the file data into data blocks? I know it doesn't say what quantity exactly the numbers give, but this should safely allow us to distinguish if the block resolves more elements/molecules/ions, as @vsnever pointed out. The Eirene class has now attributes as |
|
Just to add, what I proposed is kind of what is being done now, but breaking the namespaces more and documenting the mapping somewhere would give us in my opinion a nice opportunity to raise warnings and errors (as @jacklovell suggested) and also to react to differences in data availability between versions when building up plasma object, for example: |
Yes, you are correct. The files with label lines before each data block can be parsed without problem. The only problem is to parse the files with versions in the range from 20071209 to 20160829. |
I have only access to versions 2017+, it will probably be the best to leave up to you two to resolve problems with these versions, I don't see where I could contribute. Anyway, let me know if I could be of any use. |
Huh. I can see fort.44s with 20070912 and 20071209. No matter: if anybody has a burning desire to read these rogue 20070912 files we can always test and add them later. For now I'll test 961228, 20000727, 20071209, 20080706 and 20081111, as these are all the pre-2013 versions I have access to. |
|
I've managed to test 961228, 20000727, 20071209 and 20081111: these came from runs on the UKAEA computers which had all 3 required raw files for Cherab to read the simulation. All of these look at least qualitatively sensible to me, so I'm happy to merge the changes. We can implement a more generic reader for labelled fort.44 versions (>=2016) in a separate PR. |
This adds a fort.44 parser for the Eirene fort.44 file versions older than 20071209. This parser does not read total radiated power by neutral atoms ('eneutrad'), which was introduced in version 20071209. It is suggested to use this parser also for versions 20071209. 20080706 and 20081111 as a workaround until a generic parser is created. See discussion in #32 and #39.