Dear Patrick,

I think this is a move in the right direction. Good to have a clear strategy, 
otherwise the complexity will quickly get out of control.



> On 3. Dec 2017, at 13:52, Patrick Eriksson <> 
> wrote:
> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

arts_dev.mi mailing list

Reply via email to