Software shouldn't change their inputs

[FerreolS]

To prevent any surprise and to simplify the tracking by OImaging, the software should update only the OUTPUT PARAM table. It can add new HDU image if needed but shouldn't change the HDUs presents in the input file.

[jsy1001]

Could you be more precise as to what is required? BSMEM doesn't intentionally change any of the input tables, but it reads their contents into memory and writes out new tables containing the information it read in. Hence there may be changes such as removal of keywords that BSMEM isn't expecting.

The order of the tables is changed, but I would hope that OImaging is robust to that.

[FerreolS]

Yes, I forgot this case. Changing the order of keywords and table values is ok as it does not change the information content.

[FerreolS]

The software should add an extra column with the modeled values to the OI_VIS2, OI_VIS,
OI_T3 (and OI_FLUX if needed) tables. As suggested by @emmt , the software must flag the rows that were not used (with a NaN?) rather than removing these rows.

[jsy1001]

@FerreolS By "not used" do you mean excluded by USE_VIS etc., flagged (True value in the FLAG column), or something else? Why is it necessary to flag unused data in a new way if the excluded data can be inferred from the input prameters and/or FLAG columns?

[FerreolS]

My concern was about WISARD, that need T3 and VIS2 at the same timestamp. If for some reason there is no corresponding VIS2, the T3 will not be used . It's value should stay in the table but must be flagged somehow. Am I right @GillesDuvert ?

[jsy1001]

There is a potential edge case that could apply to BSMEM. It concerns the UVMAX parameter, which isn't implemented in OImaging yet. This tells BSMEM to filter the input data at the specified UV radius.

At the moment, BSMEM applies a UV radius filter in two situations: (a) if UVMAX is specified and is smaller than the maximum UV radius in the data; (b) if the initial image pixel size is larger than \lambda_min / (6 B_max). At the moment if case (b) applies the corresponding UVMAX value is written to the input parameters HDU of the output file, potentially overwriting the original UVMAX specified by the user.

I'm not sure of the best solution here - suggestions welcome!

[GillesDuvert]

Hi I have mixed feelings about #12 (comment) above.
Even if some (u,v) point was not used because V2 is missing, the reconstruction is an image that holds everywhere, so a model V2 and a model T3 is available at each u,v point. This goes also for measurements that are too noisy, WISARD drops them (error on 'myopic' complex visibilities is way too large). If the, say, observed V2, is flagged (or NULL?) it does not prevent to write a model_v2 IMHO.

[GillesDuvert]

But, back to the issue title, the main motive is to have the whole input image + input image header unchanged, yes?
(something I would have sworn was the case for Wisard)

[GillesDuvert]

done.

[FerreolS]

At the moment, BSMEM applies a UV radius filter in two situations: (a) if UVMAX is specified and is smaller than the maximum UV radius in the data; (b) if the initial image pixel size is larger than \lambda_min / (6 B_max). At the moment if case (b) applies the corresponding UVMAX value is written to the input parameters HDU of the output file, potentially overwriting the original UVMAX specified by the user.

This case raise two concerns for me:

• a parameters is (over)written in the INPUT PARAM table: should we rather keep the original value and INPUT and put the new value in OUTPUT? In that case the GUI could be able to detect this change and inform the user.
• the "Pixel size too large for data" message is in the log but the user attention is not raised on it. How should we implement a way to raise warning ? by a keyword WARNING (containing just a flag or a complete warning message) or by letting parsing the log looking for warning? Or should we pop up those previsible warning in the GUI when clicking on the run button?

[FerreolS]

BTW it seems that on this particular UVMAX issue, the message
ERROR : ** Message: 15:42:23.762: Pixel size too large for data is in the log even if the resolution is ok :

BSMEM_CI_VERSION: bsmem-v2.2.1-2021-12-16T14:08:21+00:00
cmd: "bsmem-ci /usr/local/tomcat/temp/uws/UPLOAD_1645113576690_inputfile /usr/local/tomcat/temp/uws/UPLOAD_1645113576690_inputfile.out"
ERROR : ** Message: 15:59:36.727: Pixel size too large for data
ERROR : ** Message: 15:59:36.731: Negative/zero values in prior image are not permitted. All have been replaced by 1e-08.
Bispectrum noise:	Classic elliptic approximation 
Maximum uv radius:	4.954e+07 waves
Array resolution:	2.0820 mas
Pixel size:		0.1000 mas
Image dimension:	200 pixels
Image fov:		20.00 mas
Pix/fastest fringe:	41.6396
Entropy functional:	Gull-Skilling entropy
Hyperparameter scheme:	Chi2 = N method
Maximum n# iterations:	50
Initial flux:		0.010000