Question about value of ref_tau_max

[jbusecke]

Hi,
we have started using aerobulk-python to recompute air-sea fluxes offline, and are running into an error indicating that the algorithm computes too strong wind stresses. I was wondering if the chosen value of ref_tau_max is more of a rule of thumb or based on some strict criteria.

Is there a reason why we should not allow stresses > 5 N/m^2? For some context we are working with quite high resolution (1/10 deg) coupled climate model data, so is there a chance that for these higher resolution cases the value should be adjusted.

Our preliminary results indicate that this is only an issue with some of the algorithms (ncar and ecmwf do not show this problem in our test dataset, but the other algorithms fail with the above error), and I am inclined to just try to raise the value of ref_tau_max = 6 (or similar) unless that is not recommended for other reasons.

[brodeau]

Hello!

Sure, I definitively picked this value out of the blue ;)
So a ref_tau_max up to 10 N/m^2 could be acceptable!
I guess experimentalists could tell us what's been observed under hurricane force winds...

I'm not surprised for NCAR, as it has this "plateau" in hurricane force winds for C_D as you can see on Fig.2 of the aerobulk README.

Cheers for the good work in aerobulk-python btw! I wasn't aware of it, cool to see it's getting somewhere! Don't hesitate to include me in some discussions or development ideas, if that would make sense of course!

/laurent

[jbusecke]

Thank you for the response @brodeau.
This is very helpful. I think the cleanest way to implement this would be here in aerobulk directly (I have started #16) if that would work for you here.

Alternatively we could try to overwrite this value in our python wrapper but that would mean the behavior of the code would diverge between aerobulk and aerobulk-python to a degree (so I would favor the former approach).

Cheers for the good work in aerobulk-python btw! I wasn't aware of it, cool to see it's getting somewhere! Don't hesitate to include me in some discussions or development ideas, if that would make sense of course!

Thank you for the offer. I think it would indeed be very helpful to have a discussion about both projects. Would you be open to a zoom meeting with members of our group (@rabernat, @paigem, @TomNicholas) some time towards late October maybe? We could prepare an overview of the science goals we are aiming to answer using aerobulk/aerobulk-python, and maybe prepare some questions about the implementation?

[jbusecke]

I have started a twitter thread to get some input on what value might be a good max value. From initial responses, we might even consider a higher value as 20 N/m^2?

[milancurcic]

Thank you @brodeau for this nice library and thank you @jbusecke for making the Python bindings.

I recommend removing the check altogether.

I think it's OK for a library procedure to fail on bad user input or if the algorithm fails. However, here an output value is checked against some threshold, so it doesn't test the user input nor the algorithm. A more meaningful check would be to check the user input values to ensure that they fall within the range of the dataset that was used to create the bulk formula. For example, for COARE 3.5 you could check that the input wind speed scaled to 10-m is < ~23 m/s.

Whether you want to do this is a question of design: Do you intend the library to be always correct (inputs must be in range) or more useful (inputs can be out of range and modelers can use it)? I recommend the latter but documenting the range of input values for which the bulk formula was derived from and expected to work correctly.

And, this check being done for each element in the nested loop will incur some performance penalty.