While digging into #31 with @paigem I looked at the aerobulk code, and it seems they do not use the mask for the computation at all? As far as I can see they only time the mask is used in the autodetermination of the humidity and the range checks of inputs here. The actual computation still runs on those values? If the calculation does not return missing values for the mask, why even use it in the first place?
This begs an important question for me:
Do we even need to call AEROBULK_INIT? I believe that most of the trouble we tried to fix in #11 was related to the range checking in AEROBULK_INIT (ctl_stop is only called in mod_aerobulk.f90 and never in mod_aerobulk_compute.f90, which is the actual code we are wrapping). They only call STOP in two locations here and here.
We already check the valid algo input in the xarray wrapper (here) and I think it would be reasonable to restrict out code to only accept one 'type' of humidity (specific humidity is the one that Aerobulk actually wants, and I think our models actually provide that).
Additionally I think that I am tending to think we should handle out-of-range-values on the numpy wrapper level, but we can discuss that in the meeting later today.
So in summary, I think it is worth trying to remove all calls to AEROBULK_INIT and just call AEROBULK_COMPUTE with values that we have cleaned on the numpy level?
While digging into #31 with @paigem I looked at the aerobulk code, and it seems they do not use the mask for the computation at all? As far as I can see they only time the mask is used in the autodetermination of the humidity and the range checks of inputs here. The actual computation still runs on those values? If the calculation does not return missing values for the mask, why even use it in the first place?
This begs an important question for me:
Do we even need to call AEROBULK_INIT? I believe that most of the trouble we tried to fix in #11 was related to the range checking in AEROBULK_INIT (
ctl_stopis only called inmod_aerobulk.f90and never inmod_aerobulk_compute.f90, which is the actual code we are wrapping). They only callSTOPin two locations here and here.We already check the valid algo input in the xarray wrapper (here) and I think it would be reasonable to restrict out code to only accept one 'type' of humidity (specific humidity is the one that Aerobulk actually wants, and I think our models actually provide that).
Additionally I think that I am tending to think we should handle out-of-range-values on the numpy wrapper level, but we can discuss that in the meeting later today.
So in summary, I think it is worth trying to remove all calls to AEROBULK_INIT and just call AEROBULK_COMPUTE with values that we have cleaned on the numpy level?