question about irregular longitude and latitude, and many times

[fecampos]

Dears, I ask two questions: 1) In constant.hpp I can choose UNIFORM_LON_GRID=false, and UNIFORM_LAT_GRID=false, It means longitude and latitude would have the form: lon(i,j) and lat(i,j)?

2) In my netcdf file, I have 2208 times. When I run coarse_grain_scalars.x I add --Nprocs_in_time 2208, I am supposing this command allows doing the parallelization. Is it correct?

Best regards

[bastorer]

Hi, sorry for the slow reply, Thanksgiving holidays last week :-)

1. At the moment FlowSieve requires a mesh grid, such that the latitude grid is independent of longitude, and the longitude grid is independent of latitude. The uniform grid flags turn on different optimizations to reduce expensive calculations when possible.
2. The --Nproc_in_time flag specifies how many MPI ranks the different times should be divided across. So, --Nprocs_in_time 2208 would mean each MPI rank would apply coarse-graining to a single time. This would require you running the job with 2208 MPI ranks though. If your netcdf file only has one depth, then you can actually leave out the --Nprocs_in_time flag, since the program will assume that all of the MPI ranks are being used to divide the time dimension, since the singleton depth dimension can't be split.

Hope that helps! Ben

[fecampos]

Dear Ben, thank you so much for your response, currently, I could run FlowSieve using another input data (high-resolution surface currents) and modifying constants.cpp (rho0 = 1, EXTEND_DOMAIN_TO_POLES = false, CARTESIAN = false, PERIODIC_X = false, PERIODIC_Y = false, KERNEL_OPT = 0, KernPad = 1.1) for my specific case. In that sense, I would like to understand the advantage of using coarse_grain_helmholtz.cpp in place to coarse_grain.cpp.

Best regards

[bastorer]

Hi Fernando,

I'm very happy to hear that you were able to get FlowSieve up and running! I'd love to hear what kind of application you're studying some time :-) As a warning, for non-periodic x grids, the kernels necessarily deform at the edges of the domain. The same happens if the latitude (y) domain does not extend to the poles. If you're using deforming kernels anyways, this is irrelevant. If not, it's worth keeping in mind that your kernel will still deform near the domain 'edges' even if deforming kernels is turned off.

Back to your question: in spherical coordinates, you cannot directly filter the velocity fields, unless the velocity field is already purely toroidal (2-d incompressible) or potential (irrotational). Instead, you need to filter the corresponding Helmholtz scalars.

Hussein Aluie has a 2019 paper "Convolutions on the sphere: commutation with differential operators" (https://link.springer.com/article/10.1007/s13137-019-0123-9) that goes through the mathematical basis for why we need to use Helmholtz projections to filter velocities in spherical coordinates.

Regards, Ben

[fecampos]

Hi Ben, thank you so much for your help. My PhD research is focus on multiscale kinetic energy transfer at air-sea interface from a numerical point of view. In that sense, I believe coarse-graining method will be the best tool to separate balanced motions and investigate their kinetic energy exchange across energy scale transfer term (Pi).

Best regards, Fernando