Re: [arts-dev] Retrieval units and transformations

2017-12-04 Thread Stefan Buehler 
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.

Cheers,

Stefan

> 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
> arts_dev.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi



smime.p7s
Description: S/MIME cryptographic signature
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Re: [arts-dev] Retrieval units and transformations

2017-12-04 Thread Richard Larsson 
Hi Patrick,

Comments:

About the current setup, it is indeed a heritage from the past.  I just
copied your setup.  You had all unit conversion local.

I like the idea to allow more units but I think this should be handled at a
later stage than the iy-functions.

I have argued before that it would be a very good idea to ensure that all
output from iy-functions are purely dependent on the physics of the
underlying calls --- that is on the inputs to the iy-functions.  All
additional conversions should happen in y-functions that have been designed
to fit with Rodgers-like computations.

This would still force the conversion of wind-field to m/s instead of Hz
after propmat^, but it would remove VMR, HSE, iy-conversion and
jacobian-transformation from this code placing it at a later stage.  (If
you want HSE, then this and all that it depends on should be input as a
variable so that the derivatives can be computed based on 'actual' theory
instead of understood theory.  You know the problem the latter has caused
because of the switch in how layers work in iy***2 functions.)

With hope,
//Richard

^It would be cleaner still to have propmat_clearskyInit set a
promat_clearsky_f_grid that is used internally and then have a cleanup-call
that converts the output calculations to m/s but this would force us to
have a propmat_clearskyCleanup function either automatically added to all
agendas or be part of the setup... so it introduces some new issues


2017-12-03 13:52 GMT+01:00 Patrick Eriksson :

> 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
>
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi