I have mentioned several times that the routine ana_psource.h should be used with extreme caution and in serial applications only


I have always recommended to not use ANA_PSOURCE, but a forcing NetCDF file instead to specify point-sources. See template Data/ROMS/CDL/frc_rivers.cdl showing how the river forcing NetCDF file looks like. It is very easy to create such file. It can be done very quicky

I have even noticed some users using ana_psource.h to specify open boundary conditions at each grid point. Well, think better about your approach and use the open boundary NetCDF files instead. This has to be done in a consistent way with a large scale model. You cannot simulate real circulations by specifying analytical point-sources at the open boundaries. Realistic ocean circulation is not as simple as that...
I hope that this is the last time that we hear from users in this forum about this issue. We will ignore such inquires, even if the river runoff is secondary. Overshooting/undershooting of tracer values next to rivers maybe associated with parallel bugs. So you are on your own here. I am now tempted to remove this capability from ROMS and used NetCDF files in all our test cases needing river runoff.
River runoff forcing is very tricky and requires experience. You need to look for a lot of things: bathymetry, land/sea masking, r-factors, vertical level distribution, temperature and salinity values, and so on. This even gets more complicated if you activated wetting and drying and/or include tidal forcing. Recall that we are representing an estuary with a single point

For stability considerations, you need to activate both TS_PSOURCE and UV_PSOURCE in 3D applications. You also need to specify both temperature and salinity
