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