More Unitful support

[longemen3000]

Great, thanks for merging!

Regarding the macro, I was thinking more of adding it before every method definition in Clapeyron that implicitly assumes a unit, and for which another version should be provided for the Unitful extension. For instance, you would write something like:

@unitsupport function x0_volume_liquid(model::SAFTVRMieModel, T::"K", z)::"m^3"
    v_lb = lb_volume(model,z)
    return v_lb*1.5
end

in Clapeyron, and this would rewrite the signature by removing the ::"unit" parts to make the code legal, while also push!ing the signature x0_volume_liquid(model::SAFTVRMieModel, T::"K", z)::"m^3" to a global variable, say const UNITSUPPORT = Expr[]. Then, in ClapeyronUnitfulExt.jl you would collect the signatures from C.UNITSUPPORT and make a new method, for instance in that case it should create:

function C.x0_volume_liquid(model::SAFTVRMieModel, T::Unitful.Temperature, z; output=u"m^3")
    _T = ustrip(u"K", T)
    res = C.x0_volume_liquid(model, _T, z)*u"m^3"
    return uconvert(output, res)
end

Such a design would allow to specify everything directly in the initial code, so there would be no duplication of information, and no risk of forgetting to update the extension at the same time as the code. If I manage to find some time during winter break, I'll try to see if that's doable (if you find the design OK).

@Liozou is ok if we follow this discussion here?

[longemen3000]

some things i noticed:

• the x0_property functions are not really meant to support units. In the sense that are the base of how some EoS define starting points, and, from the point of an external EoS developer, it is cumbersome to define an starting point and defining the same function to support units.

• i like the idea of annotating interface functions, not so much the idea of using global state to pass around code. maybe, what can be done is that macro lowers to:

function VT_property(model,V,T,z,output = (nothing))
              st = standardize(model,v,T,z)
            _v,_T,_z = state_to_vt(model,st)
            res = C.$VT_fn(model, _v, _T,_z)*$unit
            return my_uconvert(output, res)
end

or something like that. my idea is that nothing is equivalent to the identity function, so my_convert(::Nothing,x::Number) === x. when a unit is provided, my_uconvert could perform the adequate transformations

[Liozou]

the x0_property functions are not really meant to support units. In the sense that are the base of how some EoS define starting points, and, from the point of an external EoS developer, it is cumbersome to define an starting point and defining the same function to support units.

That support can be reverted easily at this point, do you want me to open a PR? I think it's also fine to keep it since they are, after all, part of the documented API of Clapeyron. For instance, they might be used by an end-user in order to get a quick-and-dirty estimate for a value, if speed is more important than precision. So I tend to consider as deserving of a unit support as the rest of the documented function. If they should only be used by Clapeyron's developers, should they not be part of the developer documentation instead?

i like the idea of annotating interface functions, not so much the idea of using global state to pass around code. maybe, what can be done is that macro lowers to: [...]

That could be doable. But it will need a bit more rewriting of the function because you can't simply do *$unit in a context where the unit may not exist: it could be possible to do something like

res = C.$VT_fn(model, _v, _T,_z)*(isnothing(output) ? true : unit)

but the main issue is that the unit itself cannot be written in the code: you can't write u"m^3" in a code where Uniful may not have been loaded. The only solution I see is to write something like @eval u"m^3" or rewrite the expansion of the @u_str macro (basically into Unitful.lookup_units([Unitful, WhateverUnitfulExtension], :(m^3))), but in any case the result will be type unstable since it needs to be computed at execution instead of lowering.

I could be overlooking a simple solution to this issue though, please let me know if you can think of a type stable alternative!