search

JMMC-OpenDev / OI-Imaging-JRA

Design and specification of an interface to image reconstruction and model fitting from optical interferometric data
4 stars 6 forks source link

Added comment on writing model data to OIFITS. #5

Closed jsy1001 closed 2 years ago

jsy1001 commented 9 years ago

Follow-up comments welcome!

emmt commented 9 years ago

The idea of adding columns is to make thinks simple for a comparison data and model value being aside. Otherwise, displaying/comparing the two may be tricky. Of course, on the imaging algorithm side, you have to keep track of the original data but it is mostly the case if you wnat to produce a consistent pseudo target data (i.e. keep track of TIME, MJD, ARRNAME, INSNAME, STA_INDEX, etc.)

Besides, but it is perhaps not clear, the idea is not so to output all provided input data but whatever data has been taken into account for the reconstruction.

jsy1001 commented 9 years ago

I'm happy to keep the idea of extra columns for the model data.

What should happen if some of the data are being ignored, either as specified by the user (e.g. USE_VIS parameter) or if they are rejected by the algorithm for some reason (e.g. not self-calibratable in WISARD) ? Should model values for these data be calculated regardless? If not, there might be a mixture of calculated model values and NULL in the additional column (if all NULL, the column could be omitted).

jsy1001 commented 9 years ago

Sorry, I've just noticed that you answered my question already! It seems that the image reconstruction software should only write model values corresponding to the data that were used for the reconstruction. The table cells corresponding to data not used for the reconstruction should be filled with NULL values. If an entire model column would be NULL, may the column be omitted?

Conversely, I think the output file should contain all of the data that were supplied as input, so that the user can enable use of additional data simply by modifying the data selection parameters (USE_VIS, USE_VIS2 etc).

emmt commented 9 years ago

Ok that seems to be a better idea to keep all input data.

For the model of unused data, using NULL is the more logical (and then omitting the column if all elements are NULL). Using the current image it is however possible to compute a model for all input data. It could then be an option to do that. On output, there could be an optional column of flags indicating for each data whether: data was used and model provided, data was not used but model provided, and neither data was used nor model provided. I just mention this possibility for completeness but it may add to much complexity for the image reconstruction software. So your solution has my personnal preference as it is consistent and the simplest (we could add the optional column of flags later if it appears to be really needed).

jsy1001 commented 9 years ago

On 04/07/15 08:29, Éric Thiébaut wrote:

Ok that seems to be a better idea to keep all input data.

For the model of unused data, using NULL is the more logical (and then omitting the column if all elements are NULL). Using the current image it is however possible to compute a model for all input data. It could then be an option to do that. On output, there could be an optional column of flags indicating for each data whether: data was used and model provided, data was not used but model provided, and neither data was used nor model provided. I just mention this possibility for completeness but it may add to much complexity for the image reconstruction software. So your solution has my personnal preference as it is consistent and the simplest (we could add the optional column of flags later if it appears to be really needed).

— Reply to this email directly or view it on GitHub https://github.com/emmt/OI-Imaging-JRA/pull/5#issuecomment-118479319.

OK, let's go with my suggestion for now then.

For the parameters in Table 1, we should add a column to define which are optional for the input file. In general parameters should only be omitted from the output file if they are "not applicable".

For optional parameters, I think omitting the parameter from the input file must be allowed. What do you think about also allowing the parameter to be included but with a NULL value i.e. value field filled with spaces (see Sec. 4.1.2.3 of the FITS standard) ? This is less convenient under some circumstances, but might be preferable because its more explicit.

In general, not specifying an optional parameter can mean either "use your fixed default value" or "choose something appropriate given the data". In both cases the actual choice made should be written to the output file. For example, in the output file the value of TARGET should always be an object identifier from the supplied data.