Hi Simon, Richard and all,

I started to think about how to allow a log10 retrieval "unit" for scattering quantities. As often happens, this ended with that I want to make a general cleaning and reorganisation.

My idea is to move towards a more clear distinction between unit and transformations. In addition, we have to deal with two types of transformations, linear and non-linear. I think these three shall be applied in the order: unit, non-linear and linear.

Comments:

unit: This would now just be pure unit changes, such as "nd" (number density). Later I would also like to allow relative and specific humidity for H2O. We could also allow "C" for temperature ...

(Units changes will be specific for each retrieval quantity, while transformations shoul be implemented in a general manner.)

Non-lin transformations: I would like to remove the "logrel" option (now an unit option). And instead generally introduce "log" and log10" (without ruling out to add more transformations, such as tanh+1?)

Linear transformations: As already introduced by Simon.

The unit part will be handled by the iy-methods. For the transformations I suggest to extend the scope of present jacobianTransform (as well as merging it with jacobianAdjustAfterIteration, that handles a rescaling for "rel" necessary for iterative OEM).


All: Comments? Something that I have missed?


Richard: The handling of units seems a bit messy to me. The function dxdvmrscf is applied in get_ppath_pmat_and_tmat, but only if from_propmat. dxdvmrscf is also applied in adapt_stepwise_partial_derivatives. This confuses me, but could be an heritage of my old code. Would it not be simpler if the core code just operates with ARTS default unit, i.e. vmr for abs species? And then the conversion is done only on the final jacobian values (along the ppath). This should be a general function, called towards the end of all iy-methods providing jacobians. As far as I can see that should work, and should give cleaner code. Agree? Or have I missed something?

Bye,

Patrick
_______________________________________________
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Reply via email to