lesgo-jhu / lesgo Goto Github PK

I couldn't find any details on how the code is parallelized (except for maybe closed issue #6). I've used a version a version of the code in the past where only the z direction was partitioned between cores (slab decomposition), but I'm in need of a model that has better scaling (which generally codes by doing pencil decompositions).

Is there a place where I can read about these details and maybe see a scaling analysis of the code? If not, can someone briefly describe how the code is parallelized?

Thanks!

Hi all,
A quick question. What is a good test-case (in terms of problem size), to conduct some strong scaling tests up to 512cores?

When I try to install cmake before using lesgo, error occurs:
The C compiler does not support C++11 (e.g. std::unique_ptr)

Has someone got some advice on this?

The rotational form of the convective term is written as $u_j\left(\frac{\partial u_i}{\partial x_j}-\frac{\partial u_j}{\partial x_i}\right)+\frac{1}{2} \frac{\partial}{\partial x_i}\left(u_j u_j\right)$, I found the code for computing $u_j\left(\frac{\partial u_i}{\partial x_j}-\frac{\partial u_j}{\partial x_i}\right)$ in convec.f90, yet the rest of the convective term, i.e., $\frac{1}{2} \frac{\partial}{\partial x_i}\left(u_j u_j\right)$ is missing, why is that?

Hello,

I was recently trying to debug a build error with your software with a student. It turned out that the contents of /usr/local/lib were different on our cluster for different machines and it would compile on some machines but not others. I narrowed it down to these lines: https://github.com/lesgo-jhu/lesgo/blob/master/CMakeLists.txt#L70-L71. After commenting these lines out the libraries were found in standard locations and it compiled fine on all machines.

The suggestion: consider removing these lines and let people modify them via:
https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PATH.html#variable:CMAKE_PREFIX_PATH

Feel free to close this issue.

The z-planes code for the CGNS output was giving segmentaiton faults. I commented the code out and now issue a warning if these are used.

Merge the Lesgo-ADM Nacelle Tower with the latest version

Hi,

In the Standard Smagorinsky Model implementation, has the Co(or Cs, the Smagorinsky Constant) value been included twice?

Here are two lines from sgs_stag_util.f90:
On line 130,
l(1) = ( Co**(wall_damp_exp)(vonkzz(1))(-wall_damp_exp)&
+ (delta)(-wall_damp_exp) )**(-1._rprec/wall_damp_exp)
On line 234,
Nu_t(jx,jy,jz) = S(jx,jy)*Cs_opt2(jx,jy,jz)*l(jz)**2

You can see that the Co already been used in l(1) calculation, so only for the Standard Smagorinsky Model implementation, you do not need to include it again in the calculation of Nu_t(jx,jy,jz). FYI, for the other models, line 234 is alright.

Please let me know if I'm wrong.

Thanks,
Rubel.

Hey, I'm new to running this simulation, so I'm not sure what normal behavior is like or how to diagnose this error, but compiling and then running OOB lesgo.config returns this:

(base) [lucas_spangher@ln002 lesgo]$ ./lesgo-mpi-cps-turbines-scalars

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0 0x2b2966ecf3ff in ???
#1 0x544965 in ???
#2 0x4327fb in ???
#3 0x487979 in ???
#4 0x40335c in ???
#5 0x2b2966ebb554 in ???
#6 0x4033ab in ???
#7 0xffffffffffffffff in ???
Floating point exception

Any pointers or advice appreciated, no pun intended!

On the documentation for the solver, there is a note about potentially allowing decomposition of the "slab"-planes along the y-direction... I wonder if there is a developing route in place for such development? I think it would add tremendous capabilities when modeling rotating flows (geophysical scale)...

I have successfully built Lesgo on a Cray system with the Cray compiler. However I am getting input errors at runtime. A bit of debugging shows the source of error is on parse_vector_real :

 output_block$read_input_conf$input_util_@input_util.f90:482
 parse_vector_real$input_util_@input_util.f90:825

Any ideas ?