Porting equation of state related quantities from PyDom.

[lesommer]

see PyDom.eos

• PyDom.eos to oocgcm to oocgcm.oceanfuncs.
• possibly in a oocgcm.oceanmodels.eos first for model specific versions of eos.
• possibly with numba for non-trivial equations.

[lesommer]

or rely on

• gsw for teos10 : pip install gsw
• seawater for eos80 : pip install seawater

[rabernat]

I have a fortran module which I extracted from POP to compute the JMD95 EOS. https://bitbucket.org/ryanaberanthey/pop_water_mass/src/master/watermasstools/jmd95.F90?at=master&fileviewer=file-view-default

I compiled it with f2py and it works great, super fast.

This could be a good approach.

[lesommer]

thanks for the input Ryan. Providing access to JMD95 would be a very good addition to the library.

I am a bit worried though with the idea of using externally compiled code in oocgcm. I would like the library to be as easy to deploy as possible and therefore I would like to use pure Python when feasible and avoid relying to much on FORTRAN and/or C.

An option could be to rewrite this module in pure python with numba or numpy based functions. Do you think that would be a lot of work ? do you think that the performances will be critically reduced ?

[rabernat]

The pure Python TEOS10 is extremely slow in my experience. I think numba is a very promising idea for the EOS.

Sent from my iPhone

On May 28, 2016, at 6:18 AM, Julien Le Sommer notifications@github.com wrote:

thanks for the input Ryan. Providing access to JMD95 would be a very good addition to the library.

I am a bit worried though with the idea of using externally compiled code in oocgcm. I would like the library to be as easy to deploy as possible and therefore I would like to use pure Python when feasible and avoid relying to much on FORTRAN and/or C.

An option could be to rewrite this module in pure python with numba or numpy based functions. Do you think that would be a lot of work ? do you think that the performances will be critically reduced ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[lesommer]

there is also a pure python version of jmd95 here.

[jinbow]

Python JMD95 from lesommer's link is originally from the MITgcm link. I agree with Ryan that the pure python version is a bit slower than fortran code, but it could be modified to work better with multi-dimensional array. The speed limitation will then be associated with numpy.

[lesommer]

thanks for your input, Jinbo.

As mentionned above, I would a priori prefer to avoid compiled code in oocgcm, except if really necessary.

since we are here only talking about a polynomial, I would not expect a python/numpy code to be more than say 50% slower than FORTRAN. plus we can probably get a speed-up with numba.

so I guess this probably needs someone to do a clean benchmark of the several options.

I will probably start by rewriting a jmd95 eos from scratch for these tests and let you know about the results.

[lesommer]

just coded a numba implementation of spice in eos.misc for profiling the execution time.

[simon3122]

Hi Julien, Did you get the chance to do the profiling on the spice computation? Why not get a working version of the eos and try thinking about performance then? cheers

[apatlpo]

Simon implemented a non-optimized version of JMD95 (code from pydom), see https://github.com/lesommer/oocgcm/commit/e27d04d74f39020916dc11d6ba2c9e2cbed38e19 He is currently testing it. There seems to be unresolved issues with large grids. more details to come