CDO

Calc:

 newValue = round (sqrt (abs (noaaValue * 230.4) ) )

Error ...

In JS is like this :

newValue = Math.sign(value) * Math.pow(Math.round(Math.sqrt(Math.abs(noaaValue * 230.4))),2) / 230.4

Yes. See this section of the documentation for cdo operator expr: https://code.mpimet.mpg.de/projects/cdo/embedded/index.html#x1-2970002.7.1

Thanks for the link, there are so many possibilities, that I missed this.

If I understood correctly :

nint(x) === Math.sign(x) * Math.round(x)

If I converted my current calculation, JS to Fortran (?), the equivalent would be:

// JS
newValue = Math.sign(value) * Math.pow(Math.round(Math.sqrt(Math.abs(noaaValue * 230.4))),2) / 230.4
    ===
// Fortran
newValue = sqr(nint(sqrt(abs(noaaValue * 230,4)))) / 230.4

I have a last question.
In reality, my result is truncated to 6 decimal (= newValue.toFixed (6))
Is it possible to do the same?

Thanks

I don't know java but a quick duckduckgo indicates that the nint command is similar to the java Math.round command; both round to the nearest integer. Theoretically you can replace Math.sign with nint(noaaValue/abs(noaaValue)).

newValue = nint(noaaValue/abs(noaaValue)) * sqr(nint(sqrt(abs(noaaValue * 230.4)))) / 230.4

As for precision, I suggest you open another thread with that specific question. There is the -b <nbits> command line option (https://code.mpimet.mpg.de/projects/cdo/embedded/index.html#x1-70001.2.1) that specifies the number of bits of precision, but that is not the same thing as converting to a fixed decimal. A cdo programmer will have to step up to answer this one. But I would ask you to consider why you are converting to fixed decimal.

I re-read the precision option and looked up *.toFixed. *.toFixed converts to a string. The precision option is only to choose between float32 and float64 with grib output. Again you need to ask why you need to do this. Maybe you do not.

After asking the questions, last night, I implemented all of this.
I encountered some difficulties but it seems to me that in the end it works as intended.

cdo exprf,cnvUV gfs.t12z.pgrb2.1p00.f006 test006

cnvUV file :

10u = (10u > 0) ? 1 : -1 * sqr(nint(sqrt(abs(10u * 230.4)))) / 230.4;
10v = (10v > 0) ? 1 : -1 * sqr(nint(sqrt(abs(10v * 230.4)))) / 230.4;

If I compare the U&V values obtained from the test006 file vs those that I calculate in JS, they are similar but not equal (probably rounding).

But TWD & TWS values, they match at 100%.
So the question on how to truncate to 6 decimal, is no longer relevant.
It does the job like that so it suits me.

1st step ok, I will tackle the rest and if I have other questions I will open a new post.

Thanks for your help

For the explanation:
I have .wnd files, they are gribs but the U&V values are in 8 bits signed (byte ?) and not float.
With this command via cdo, I can from a NOAA grib, recreate a grib equivalent to the .wnd file (U&V).

The next step is that the TM003 is not used, it is a calculation from TM009 previous TZ, TM012 previous TZ and TM006 current TZ.
I would like to be able to create the TM003 via cdo (I know the calculation).

The final goal is to be able to generate a complete grib (129 TM) similar to .wnd files that I could use in other software.

As long as the other software support the full grib2 spec you should have no reason to worry about the format is which the numbers are saved.
Nice use of ternary!

Hi,
Thanks Brendan DeTracey

Small syntax error that changes the way the expression works.
I forgot some parentheses ...

10u = ((10u > 0) ? 1 : -1) * sqr(nint(sqrt(abs(10u * 230.4)))) / 230.4;
10v = ((10v > 0) ? 1 : -1) * sqr(nint(sqrt(abs(10v * 230.4)))) / 230.4;