z_ground divergence atmo module

[SimBu]

Hi all,
I have used the atmospheric module for a few cases, and I have randomly some errors linked with the divergence of z_ground during the first time step.

It happens when I want an automatic idealized wind profile, but not on all meshes. I found once that my ground was higher than 0 in the z direction and I changed it (it worked), but then, for rest of my cases it is not...

I also found in cs_user_parameter the option cs_glob_atmo_option->compute_z_ground = false but it didn't work and searching in the src files, I saw that it is activated anyway if I want automatic wind profile.

Here is the error of my run_solver.log :

Code: Select all

Symmetric Gauss-Seidel [Z ground]: divergence after 1 iterations:
  initial residual:        -nan; current residual:        -nan



/home/simeon/codesaturne/code_saturne/src/alge/cs_sles_it.c:4667: Fatal error.

Symmetric Gauss-Seidel: error (divergence) solving for Z ground


Call stack:
   1: 0x7f118c819916 <cs_sles_it_error_post_and_abort+0x96> (libsaturne-7.0.so)
   2: 0x7f118c80f36d <cs_sles_solve+0x17d>            (libsaturne-7.0.so)
   3: 0x7f118c810779 <cs_sles_solve_native+0x469>     (libsaturne-7.0.so)
   4: 0x7f118c40880d <cs_equation_iterative_solve_scalar+0xcfd> (libsaturne-7.0.so)
   5: 0x7f118c9b8136 <cs_atmo_z_ground_compute+0x1046> (libsaturne-7.0.so)
   6: 0x7f118c51aba1 <tridim_+0x579>                  (libsaturne-7.0.so)
   7: 0x7f118c38d140 <caltri_+0x1c2f>                 (libsaturne-7.0.so)
   8: 0x7f118d265b97 <main+0x717>                     (libcs_solver-7.0.so)
   9: 0x7f118c0dd083 <__libc_start_main+0xf3>         (libc.so.6)
  10: 0x56163d86b08e <_start+0x2e>                    (cs_solver)
End of stack

If someone kows why it occurs, i would be pleased !
Best regards,

[Martin FERRAND]

Dear SimBu,
I suspect there is something wrong in you user subroutines because a ground has already been computed (from 0 to 50m) and should not be computed again.

Do you have any user subroutines which would explain the problem?
Best regards
Martin

[SimBu]

I had no user files for this case, and as far as I remember, this issue has occured on cases with no user functions. Here is the RESU file compressed. By the way, how exactly does the wind profiles is generated ? If i have a building roof on my boundary, z_ground is 0 on it so the wind profile won't be homogene with the rest of my boundaries ?

I was also surprised that z_ground is computed each time step, maybe it was developped to take in account moving mesh ? Because whant I am managing to make it workink, z_ground is calculated.

Moreover, in the setup.log, z_ground is the only field to be defined as a scalar dfrift, do you know why ?

Many thanks,

[Martin FERRAND]

Thank you for your answer.
I have no time to check the resu tonight but I can try to answer some of your questions :
- z ground is used to imposed initial and boundary profile for the velocity and the (potential) temperature with relief. In Monin Obukhov profiles we take the distance to the ground in the formula. However, meteo pressure is solved from an hydrostatic state
- z ground should not be computed each time step, we need to investigate (is it not solved in our case) except if the mesh moves.
- z ground is computed on any mesh solving div(phi e_z) = 0 with boundary condition of phi i s equal to 0 at the ground. So it is a variable with a “convective field” different from the velocity (imposed in this cas), and we use the “drift” model for that.

Best regards

[SimBu]

Thank you very much for shedding some light on the third point. Indeed I was quiet confuse on an other case while using a drift scalar because i had an error with z_ground related to drift_tau. In order to fix it, I changed z_ground in c_use_physical_properties this way :

Code: Select all

    if (!strcmp(f->name, "z_ground")){
      drift_flag = 0;
      printf("%s / key : %d\n", f->name, drift_flag);
    }

I realize now that it is not correct, how can I do it in a clean way ?

Concerning the first point, I misunderstood the goalof it, thank you !
And then, for the second point, I tried to understand myself, so maybe it will help you just a little bit ? :

cs_atmo_z_ground_compute() is the method processing while I get the nan error. it is defined in cs_atmo.c
This method is called by tridim.f90, during the initialisation (cf ligne 356).
cs_atmo_z_ground_compute() is also called by cs_atmo_compute_meteo_profiles(), also defined in cs_atmo.c
cs_atmo_compute_meteo_profiles() is called by the routine atiniv0, which is itself called by ppiniv0, called in the file inivar.f90.

To sum up, if i understand well, cs_atmo_z_ground_compute() is called two times for the initialisation

At the start of cs_atmo_z_ground_compute(), there is a condition that should avoid the re-computation / non-wanted computation :

cs_atmo.c, l.1230, with _atmo_option of type cs_atmo_option_t

Code: Select all

  if (!_atmo_option.compute_z_ground)
    return;

_atmo_option.compute_z_ground is forced to true in cs_atmo_init_meteo_profiles() ; however it is never turned to false anywhere else in the code. So i think that is why it is recomputed ? Shouldn't be an _atmo_option.compute_z_ground =false at the end of cs_atmo_z_ground_compute() ?

Anyway, thanks very much for your answer, it is really encouraging toknow that we are supported !

[SimBu]

I am facing a new initialization problem with the atmospheric module:
For two days my simulations have failed, with a nan error on initialization:

Code: Select all

Invalid (not-a-number) values detected for a field.

The errors seem to come from this step of the initialisation of the atmosphere :

Code: Select all

L2 norm of F_ext=nan, dF_ext=0.000000, F_ext_next=nan

What is weird is that the problem only depends on the mesh, because for the exact same xml file (not a single difference), and the same geometry but a more refined mesh , my simulation is not working, contrarely to a less refined mesh.

here is what I noticed :

• Issue only occurs when using automatic file. Meteo file is ok

• It depends on the mesh (with the same xml file, and the same geometry but a different mesh, the first simulation can be ok but not the second one

• It is sometimes due to a z-ground divergence as I mentioned above.

• It is sometimes an nan error

• It sometimes help to have a mesh whose coordinates are only positive (once, i just translated my geometry on x and y axis and it solved the nan error, and an other time I moved on the z axis and it solved thz z-ground divergencee error

• I tried with Med, or cgns meshes but no difference

Here are linked the two simulations with an identical geometry and xml but different meshes. Please don't pay attention to geometry or conditions, it was only for error testing. I am sorry, I overwrited the med file so I only have the mesh.input.csm

[Yvan Fournier]

Hello,

Debugging the case which fails, it seems that for some cells, the computed value of z_ground is higher than the the value of z at some faces, which lead to some formulas using log functions to fail.

I need to check with Martin, but I assume z_ground should always be lower than z, so there might be an issue in the way this is computed.

Best regards,

Yvan

[SimBu]

Thank you very much, I had come to the same conclusion, z ground could be the problem but I had not debugged. Please, let me know then what could be the solution,
Best regards,