MCPL_ouput and MCPL_input are inconsistent with file extension handling

[g5t]

Background

MCPL_output

By default the MCPL_output component uses its own component name as its output file name. https://github.com/McStasMcXtrace/McCode/blob/e56b1e3557d5ca3b3eded624a49e1ef9a22ebfff/mcstas-comps/misc/MCPL_output.comp#L93-L97 Which seems reasonable. It then specifies (in single processor mode) a file extension of .mcpl: https://github.com/McStasMcXtrace/McCode/blob/e56b1e3557d5ca3b3eded624a49e1ef9a22ebfff/mcstas-comps/misc/MCPL_output.comp#L104 And ensures that the provided filename has that extension, or adds it to a new variable as needed: https://github.com/McStasMcXtrace/McCode/blob/e56b1e3557d5ca3b3eded624a49e1ef9a22ebfff/mcstas-comps/misc/MCPL_output.comp#L106-L107 It calls an MCPL function to create the output file object https://github.com/McStasMcXtrace/McCode/blob/e56b1e3557d5ca3b3eded624a49e1ef9a22ebfff/mcstas-comps/misc/MCPL_output.comp#L110 And at the end of instrument execution it finally instructs MCPL to close and, if compiled with Gzip support, compress the file. https://github.com/McStasMcXtrace/McCode/blob/e56b1e3557d5ca3b3eded624a49e1ef9a22ebfff/mcstas-comps/misc/MCPL_output.comp#L350

MCPL_input

Perhaps sensibly, the input component does not attempt to guess a file-name; is uses the MCPL open-file interface to handle opening the .instr specified filename: https://github.com/McStasMcXtrace/McCode/blob/e56b1e3557d5ca3b3eded624a49e1ef9a22ebfff/mcstas-comps/misc/MCPL_input.comp#L90

The problem

If a user knows the name of the MCPL_output component (or specifies a filename like "/datastore/my_output_file.mcpl") they may think that they also know what to provide to the MCPL_input component as filename (e.g., filename="/datastore/my_output_file.mcpl"), but if the MCPL available at runtime includes Gzip support they will be wrong.

They are mistaken because MCPL_output/MCPL silently creates a compressed file named, e.g., /datastore/my_output_file.mcpl.gz, and MCPL_input/MCPL is strict when loading files.

A possible solution

Change MCPL_input/MCPL to look for the .gz when a user specifies a filename like /datastore/my_output_file.mcpl that doesn't exist and MCPL has Gzip support.

Similarly, it could be modified to append .mcpl and/or .mcpl.gz if no extension is specified to match the MCPL_output behavior. Then two complementary instruments which exchange information through an intermediate MCPL file can work together more-easily. E.g., two instruments with MCPL_output and MCPL_input filenames set by instrument parameters,

$ mcstas primary_spectrometer.instr
$ mcstas seconary_spectrometer.instr
$ ./primary_spectrometer.out param1=1 mcpl_filename=/datastore/my_output_file.mcpl
$ ./secondary_spectrometer.out param2=2 mcpl_filename=/datastore/my_output_file.mcpl

could work as indicated without requiring at a user check whether MCPL_ouput silently created /datastore/my_output_file.mcpl.gz instead of the requested file.

[g5t]

@tkittel Would it make more sense to change how MCPL loads files, or to add logic to MCPL_input?

[tkittel]

Hmm... I guess for now I would prefer if you update the logic in MCPL_input, since I have a feeling that I wan't to give the MCPL code itself a bit of an overhaul eventually. There is quite a bit of weird stuff going on w.r.t. gzip, extensions, zlib versus gzip executable, fat binaries, etc. Most of that was added in the early days of the project to try to make it easier for mcstas to use it, but as we are slowly moving to a more standardised development/release/deployment for both MCPL and McStas project, I am getting an urge to got and throw out all of that weirdness which now seems more like baggage than feature.

[g5t]

Under the assumption that the component should be modified (and that no one is going to do that at the moment), for future reference: https://stackoverflow.com/questions/230062/whats-the-best-way-to-check-if-a-file-exists-in-c