The number of input params should be determined by the input wavelength range

[ThomasSYLai]

The number of input params should be determined by the input wavelength range but not the resolutions modules input in the .ini file.

Another issue that has been observed is that the uncertainty seemed to depend on the number of input parameters. So an unreasonable large number of the parameters, such as what is discussed above, will lead to overestimated uncertainties.

For a spectrum with no gaps, a better way to fix this issue is to identify the input parameters by the given input spectral range. The resolutions key in .ini file is simply a pointer to what resolution the model should be using and should not be relevant to the determination of what parameters to input.

For a record, this can be changed in _initfeats() in cafe_helper.py.

[tdiazsantos]

I'm not sure if I agree with this. You talk about a very specific example, a spectrum with no gaps. But the user can chose to fit a spectrum with gaps. And I think the most general way to define what is being fitted is by specifying the R files that are necessary, which should coincide with the wavelength ranges that are going to be fitted. Otherwise the specification by wavelength ranges needs to be done by the user, who would need to go and see what is the beginning and end wavelengths in each cube. I think that's more complicated.

That being said, if the cubes would be extracted with CRETA, there is actually a way to do this automatically, because CRETA preserves the name of the band/module names where the cubes come from. That information could be used to automatically define wavelength ranges and load all the modules (without even the need for the user to specify the names of the modules in the .ini file!). However, it seems that nobody is using CRETA right now, so I'm not sure it's worth to implement that.