Float32 - usage

[AthPaschalis]

Description

@hsolleder Could you please post a comment if the code is compatible with FT - Float32 instead of Float64?

[hsolleder]

@AthPaschalis where would you like this information to be located? In the deployed documentation ?

I ran a quick test for Float32 and the model initialization crashed, I assume the same will happen for the simulation and will require some corrections with respect to the typing.

The reason is simply that Float64 is the default Float type on most machines (just like Int will be Int64), so using FT=Float64 will not crash despite relying on both FT and Float. I assume that the result of some functions needs to be cast to FT, or further parametrized, to allow the switch to Float32 (and other subtypes of AbstractFloat)

[AthPaschalis]

Precisely. I run into the same issue. It would be great to have the Float32 version, as this will likely half the computational time, and we don't necessarily need Float64 precision.

[hsolleder]

Turns out the effort involved to maintain floating-type stability is not insignificant. I tried it on UT&C, you can see it here: EPFL-ENAC/UrbanTethysChloris.jl@e87519a. Basically, you need to cast all floating-point literals to the FT type to avoid type promotion.

About the estimate of halving the computational time, I would expect a much lower benefit, as the code hasn't been optimized yet. In particular, there are lower-hanging fruits with higher benefits (static arrays, limiting allocations, using views, avoid cache misses) that could be prioritized. I'll create an issue in the TethysChloris.jl repo to track the Float32 availability