Corrected parallel bugs in ana_psource.h

[arango]

The analytical specification of point sources (TS_PSOURCE, UV_PSOURCE, and Q_PSOURCE), in ana_psource.h, are extremely tricky in ROMS parallel applications. This is due to ROMS coarse-grain parallel design that support serial, serial with tile partitions, parallel shared-memory (OpenMP), and parallel distributed-memory (MPI). It requires full knowledge of ROMS framework design and parallelism to modify this ana_psource.h. So please look at the corrected routine and study it. I highly recommend you to understand first what it is involve before attempting to modidy this routine.

The routine ana_psource.h was previously designed for serial applications without tile partitions. The example tests cases were very simple and small and didn't required running in parallel. Nowadays, there is an increased number of users using this routine for their own applications. So I decided to correct this routine for you to have an idea of what it is involved. Still the best way to specify the point sources (river runoff) in ROMS is from an input (river) forcing NetCDF. Then, ROMS will take care of all the parallel issues internally.

[arango]

I also reduced the number of significant digits when printing the the basin total volume information (stiffness.F) to standard output. Sometimes different partions give different values. This was not a parallel bug but a roundoff feature. The total volume is a reduction sum operation and it is subject to roundoff when printing more significant digits than those used in its computation. There is not need to compute this in quadruple precision since it is just a diagnotic quantity. Anyway, the quadruple precision is only supported by ifort. Many other compilers (pgf90, gfortran, g95) do not support quadruple precision computations because they are too slow. The quadruple precision needs to be activated in the MPI library.

[arango]

There are still parallel bugs in ana_psource.h. Now, the problems are in shared-memory (OpenMP) and in serial with partitions.

This a extremely difficult routine in a parallel, even for the developers. It is a good example of the parallel issues that you need to be considering when modifying ROMS. You would to think carefully when adding new code to ROMS, if you want to preserve it parallel framework integrity.

Still the best and easier way to provide point sources in ROMS via a forcing NetCDF file.