delnov / t-flows Goto Github PK

In the present form, Save_Cgns_Results and Save_Vtu_Results are very difficult to read. If a developer focuses on one model at a time (which he or she always does), he or she has to jump from one if condition to another, and make a separate checklist to see what is saved for each model. Very fuzzy.

It should be done in the following way:

if(turbulence_model .eq. K_EPS) then
   call Save_Vtu_Scalar(kin % n ...
   call Save_Vtu_Scalar(eps % n ...
   ...
end if

if(turbulence_model .eq. K_EPS_ZETA_F22) then
   call Save_Vtu_Scalar(kin % n ...
   call Save_Vtu_Scalar(eps % n ...
   call Save_Vtu_Scalar(zeta % n ...
   call Save_Vtu_Scalar(f22 % n ...
   ...
end if

if(turbulence_model .eq. HANJALIC_JAKIRLIC .or.
   turbulence_model .eq. REYNOLDS_STRESS) then
   call Save_Vtu_Scalar(uu % n ...
   call Save_Vtu_Scalar(vv % n ...
   call Save_Vtu_Scalar(ww % n ...
   call Save_Vtu_Scalar(uv % n ...
   call Save_Vtu_Scalar(uw % n ...
   call Save_Vtu_Scalar(vw % n ...
   call Save_Vtu_Scalar(kin % n ...
   call Save_Vtu_Scalar(eps % n ...
   if(turbulence_model .eq. REYNOLDS_STRESS) then
     call Save_Vtu_Cells(f22 % n ...
   end if
   ...
end if

I understand that it would mean repeating some lines of the code (Save_Vtu_Scalar(kin % n ... for example), but the way we have it now, we have repetition of if statements which are scattered over hundreds of lines of code.

Both Allocate_Statistics.f90 and Allocate_Variables.f90 try to allocate u % filt which cause the simulation to crash. I am not sure if this is solved by new Bojan implementations of model names.

When file "exit_now" is created in the running directory, the program does save the results, but doesn't exit.

In addition, if "save_now" is created, the program crashes with the following message:

Finished with User_Impinging_Jet_Profiles
At line 487 of file Main_Pro.f90 (unit = 9)
Fortran runtime error: Cannot open file 'save_now': No such file or directory

(This issue was initially raised by Muhamed in an e-mail.)

Heapsort introduced by Egor seems to be doing a good job. It makes sense for all other routines (Sort_Int..., Sort_Short..., etc) to accept the same algorithm.

In many places in the code, surface of the cell face is re-computed like this:

s_tot  = sqrt(  grid % sx(s)*grid % sx(s)  &
              + grid % sy(s)*grid % sy(s)  &
              + grid % sz(s)*grid % sz(s))
b(c1) = b(c1) + s_tot * phi % q(c2)

The code runs a couple of percent faster if it is replaced with precomputed cell face area:

b(c1) = b(c1) + grid % s(s) * phi % q(c2)

Dear guys, Egor in particular,

I have an issue with git command. My usual workflow is lately like this:

git clone https://github.com/DelNov/T-Flows
git checkout -b bojans_branch_to_fix_issue_#67

Then I am fixing the issue for a while. When happy, I do:

git commit
git push --set-upstream origin bojans_branch_to_fix_issue_#67

Then I go to our page (https://github.com/DelNov/T-Flows), find the branch I created to debug, and press a green button which says: "Compare & pull request"

Is this a good workflow or not?

Dear guys,

Based on Egor's recommendations, I come up with corrected suggestion for a typical workflow we can use for git. Please note that what I list here is not an exhaustive list of git commands and options, but rather a minimum set to accomplish daily tasks. Also note that this workflow is suggested for longer development, short bug fixes might need a different workflow. I write in first person for the time being, but will change it to second person at later stages.

Anyhow, the proposed workflow might look:

1. Fork DelNov/T-Flows to my own fork Niceno/T-Flows (if it doesn't already exist). This is achieved by pressing the Fork button in GitHub/DelNov/T-Flows

2. Clone my fork (GitHub/Niceno/T-Flows) to a local workstation. At a Linux terminal, this would be achieved with command:

   git clone https://github.com/Niceno/T-Flows

3. Since I am not forking to separate from the rest of you guys, I want to keep connected to the original repository, so I issue this command in Linux terminal:

   git remote add delnov_repository https://github.com/DelNov/T-Flows

4. I understand that it is strongly suggested to rename origin (which is a name set to repository I cloned from my fork by default) to some other meaningful name. To achieve this, I use the following command on my local workstation:

   git remote rename origin bojans_fork

5. At this point, it would be useful to check which remotes I have at my disposal, and I do it with the command:

   git remote -v

   which will give the following list:

   bojans_fork https://github.com/Niceno/T-Flows (fetch)
bojans_fork https://github.com/Niceno/T-Flows (push)
delnov_repository https://github.com/DelNov/T-Flows (fetch)
delnov_repository https://github.com/DelNov/T-Flows (push)

6. Of course, I know on which issue I will be working on. Hence, it makes perfect sense and is very advisable to make a branch for me with a name which reflects these specific developments. In my case I could create a branch called amg_dev_branch with:

   git checkout -b amg_dev_branch

7. Now, happy with the fact that I have my own fork (GitHub/Niceno/T-Flows), my own branch (amg_dev_branch) and with the fact I am still connected with you guys in the original repository (GitHub/DelNov/T-Flows) I do editing, compiling, testing, editing some more, debugging, testing, validating and verifying, and all the other things we normally do when developing simulation tools and physical models.

8. At the end of the day, I am happy with partial progress I made, and I commit my changes in a specific path:

   git commit [path_with_good_progress].

   This will store the changes I made to the local git repository on the workstation on which I work.

9. If I think that the changes are so good they deserve to be pushed to the origin of my fork (GitHub/Niceno/T-Flows) I issue a command:

   git push bojans_fork amg_dev_branch

10. However, there will come a point at which I will believe that I finished my model implementation and would like to share these developments with you guys. In such a case, I go back to web browser to my own fork (GitHub/Niceno/T-Flows), from the drop-down menu called Branch I chose the branch amg_dev_branch and press a button called New pull request to make a pull request.

Any comments? Keep in mind that this is a workflow with a minimum set of commands.

The case-based version of User_Mod_Save_Results ended up in the root directory of the Process I would fix it, but I don't know how to. I will therefore assign this to Egor, he is very prudent with git.

The code forms neighboring coefficients for pressure equations and near wall cell, and I don't think it should for the boundary condition dp/dn = 0. Check it thoroughly one day.

I found out that we have some problem, when we launch any test case with np > 1.
In Load_Cns after reading .cns file no all b.c. are correctly determined.

with following piece of code just after Load_Cns call it can be confirmed:

    do c = -grid % n_bnd_cells, -1
      print *, "c=",c, "color=",grid % bnd_cond % color(c)
    end do

checked on Channel_Re_Tau_590 and Fuel_Bundle;

in case of Channel output will tell that there is b.c. color number "10091" and it is not a random value.

This problem exist since first commit with message

" Imported sources for the first stable release."

Dear all,

For some reason bullets are not in separate lines in our readme.md file.

We also introduce LES after it was used, and never introduce RANS.

Many other abbreviations are not needed since they are never used (such as CG, CGS, AKN ...)

I will try to fix it.

Dear all,

Our readme.md, which we can see on the main DelNov page: https://github.com/DelNov/T-Flows

is still not as good looking as README.md which I have in my fork: https://github.com/Niceno/T-Flows-Last-Amg

Could it be that github accepts formatting commands in .md (stands for markdown) files only if they are called with capital letters?

Dear guys,

Is it possible that we could compute wall distance in the Process simply using this: https://www.cfd-online.com/Wiki/Transport_equation_based_wall_distance_calculation

?

Rans Channel flow computations is producing high pressure that is homogeneously distributed over cells and number of iterations for pressure is never going to zero even computation converges. It is 14-15 iterations. Also monitoring file shows that pressure is increasing but since gradient of pressure is zero it does not affect velocity field.

If you run the program in parallel and create "exit_now", the program may sometimes crash.

Hi all,

Since we are going to (re)implement a model for theta^2 (T2) and epsilon_theta^2 soon, the output will become a bit too cramped. Hence, I was thinking that re-structuring it in this way would be handy:

                                         #===============================================#
                                         #                                               #
                                         #              Time step :       1              #
                                         #                                               #
                                         #    Simulation time : 00:00:000 [mm:ss:sss]    #
                                         #    Wall-clock time : 000:00:00 [hhh:mm:ss]    #
                                         #                                               #
                                         #-----------------------------------------------#
  #=============================================================================================================================#
  #                                                        Iteration:  1                                                        #
  #--------------------+--------------------+--------------------+--------------------+--------------------+--------------------#
  # U   :  2 9.291E-07 | V   :  0 0.000E+00 | W   :  0 0.000E+00 | PP  :  0 0.000E+00 | MASS:    2.120E-11 | T   :  2 2.359E-07 #
  # KIN :  3 2.653E-04 | EPS :  2 6.763E-07 | ZETA:  3 3.552E-06 | F22 :  1 2.653E-03 | T2  :  3 2.417E-05 | EPT2:  1 8.543E-06 #
  # UU  :  2 1.935E-08 | VV  :  2 2.084E-08 | WW  :  2 1.110E-08 | UV  :  0 0.000E+00 | UW  :  2 1.306E-08 | VW  :  0 0.000E+00 #
  #=============================================================================================================================#
  #                                                        Iteration:  2                                                        #
  #--------------------+--------------------+--------------------+--------------------+--------------------+--------------------#
  # U   :  2 9.291E-07 | V   :  0 0.000E+00 | W   :  0 0.000E+00 | PP  :  0 0.000E+00 | MASS:    2.120E-11 | T   :  2 2.359E-07 #
  # KIN :  3 2.653E-04 | EPS :  2 6.763E-07 | ZETA:  3 3.552E-06 | F22 :  1 2.653E-03 | T2  :  3 2.417E-05 | EPT2:  1 8.543E-06 #
  # UU  :  2 1.935E-08 | VV  :  2 2.084E-08 | WW  :  2 1.110E-08 | UV  :  0 0.000E+00 | UW  :  2 1.306E-08 | VW  :  0 0.000E+00 #
  #=============================================================================================================================#
  #                                                        Iteration:  3                                                        #
  #--------------------+--------------------+--------------------+--------------------+--------------------+--------------------#
  # U   :  2 9.291E-07 | V   :  0 0.000E+00 | W   :  0 0.000E+00 | PP  :  0 0.000E+00 | MASS:    2.120E-11 | T   :  2 2.359E-07 #
  # KIN :  3 2.653E-04 | EPS :  2 6.763E-07 | ZETA:  3 3.552E-06 | F22 :  1 2.653E-03 | T2  :  3 2.417E-05 | EPT2:  1 8.543E-06 #
  # UU  :  2 1.935E-08 | VV  :  2 2.084E-08 | WW  :  2 1.110E-08 | UV  :  0 0.000E+00 | UW  :  2 1.306E-08 | VW  :  0 0.000E+00 #
  #=============================================================================================================================#
  #                                                        Iteration:  4                                                        #
  #--------------------+--------------------+--------------------+--------------------+--------------------+--------------------#
  # U   :  2 9.291E-07 | V   :  0 0.000E+00 | W   :  0 0.000E+00 | PP  :  0 0.000E+00 | MASS:    2.120E-11 | T   :  2 2.359E-07 #
  # KIN :  3 2.653E-04 | EPS :  2 6.763E-07 | ZETA:  3 3.552E-06 | F22 :  1 2.653E-03 | T2  :  3 2.417E-05 | EPT2:  1 8.543E-06 #
  # UU  :  2 1.935E-08 | VV  :  2 2.084E-08 | WW  :  2 1.110E-08 | UV  :  0 0.000E+00 | UW  :  2 1.306E-08 | VW  :  0 0.000E+00 #
  #--------------------+=========================================+=========================================+--------------------#
                       #    Maximum Courant number: 6.797E-02    |    Maximum Peclet number: 7.737E+05     #
                       #---------------------------+-------------+-------------+---------------------------#
                       #    Flux x :  2.00E+00     |    Flux y : -4.21E-08     |    Flux z : -5.42E-05     #
                       #    Pdrop x:  3.60E-03     |    Pdrop y:  0.00E+00     |    Pdrop z:  0.00E+00     #
                       #---------------------------+---------------------------+---------------------------#

This, of course, should go for version 0.2

In Tests/Grids directory, there is a number of cgns files with very short and cryptic names (yf17.cgns beats them all, but is closely followed by grid.cgns). Does anyone know what these files represent? Renaming them would help, adding a readme file would help even more.

(If we developers don't know what they are, users will know even less)

Dear all,
I am now writing a source code to implement the theta2 equation we discussed some time ago. To this end, I am using Compute_Turbulent.f90 as a guide. While browsing through it I came across the a strange if statement at line 105

105 if(c2 > 0) then

What I do not understand is that, a few lines (118) below and still inside this if structure, the following statement appears

118 if(c2 > 0) then
119 phi % a(c1) = phi % a(c1)-flux(s) * phis
120 phi % a(c2) = phi % a(c2)+flux(s) * phis
121 else
122 phi % a(c1) = phi % a(c1)-flux(s) * phis
123 end if

I am having a hard time following the logic here and maybe this is a stupid question, but doesn't the else at line 121 contradict the first if at line 105? I ask because if you instead look at Compute_Energy.f90 this feature is not present.

Thanks in advance,

Massimo

grid % cell_near_wall is not correctly defined because Calculate_Face_Geometry(grid) is called before Load_Boundary_Conditions in Main_Pro.f90 so wall and wall_flux is not defined when cell_near_wall is searched.

For any test case for any compile options (CGNS_HDF5=yes/no) I see a bug now:
change save result interval to 1:

RESULTS_SAVE_INTERVAL 1

And run this case.
Soon afterwards you will noticed code is crashed, beaus line length capacity was not enough.
List of files looks like this:

chan-ts000001.cgns
chan-ts000001-ts000002.cgns
chan-ts000001-ts000002-ts000003.cgns
chan-ts000001-ts000002-ts000003-ts000004.cgns
chan-ts000001-ts000002-ts000003-ts000004-ts000005.cgns
chan-ts000001-ts000002-ts000003-ts000004-ts000005-ts000006.cgns
chan-ts000001-ts000002-ts000003-ts000004-ts000005-ts000006-ts000007.cgns
chan-ts000001-ts000002-ts000003-ts000004-ts000005-ts000006-ts000007-ts000008.cgn
chan.cgns
chan.vtu
chan-ts000001.vtu
chan-ts000001-ts000002.vtu
chan-ts000001-ts000002-ts000003.vtu
chan-ts000001-ts000002-ts000003-ts000004.vtu
chan-ts000001-ts000002-ts000003-ts000004-ts000005.vtu
chan-ts000001-ts000002-ts000003-ts000004-ts000005-ts000006.vtu
chan-ts000001-ts000002-ts000003-ts000004-ts000005-ts000006-ts000007.vtu
chan-ts000001-ts000002-ts000003-ts000004-ts000005-ts000006-ts000007-ts000008.vtu
chan-ts000001-ts000002-ts000003-ts000004-ts000005-ts000006-ts000007-ts000008-ts0

Hi all,

As you could already see, our package has a number of modules: Grid_Mod, Var_Mod, Flow_Mod, etc. Their function is to cluster together variables to describe a common entity (grid for example, variable (Var_Mod) for another, Gradients (Grad_Mod), ... etc).

They all follow the same naming convention, i.e. their names end up with a _Mod. One module doesn't follow this convention, namely the Turbulence module. The reason it doesn't is because I thought that Turbulence_Mod is somewhat too long and impractical. But, if we abbreviate it as Turb_Mod it would me manageable. It also wouldn't be the first module to use abbreviation in the name, the above mentioned Grad_Mod and Var_Mod are other examples, but we also have Comm_Mod (for Communication)

My point is: I suggest to change the name of folder where module for turbulence is from Turbulence to Turb_Mod. It would be more consistent.

Is everyone OK with this?

At the beginning of our joint endeavor, we agreed on certain coding standards.

For example, we decided to call all subroutines, functions, modules and types with first upper-case letters (such as Compute_Pressure_Simple, Correct_Velocity, etc.) In addition, modules and types should have extension _Mod and _Type added in the end (hence Grid_Mod, Control_Mod, Coarser_Grid_Type, etc.)

All constants; not physical model constants such as C_mu, but constants declared with parameter; should be called with all letters capital (HUGE, SMALL, PI, ONE_THIRD, etc.) These can't be changed during the execution of the program.

All variables, be it simple data types like integers or reals or derived data types like Grid_Type, should be written in all lower-case letters (grid, u, v, w, kin, eps, etc.)

In addition, we agreed to write all directory names using the same rules as functions, subroutines, modules and type to match file names with functions, subroutines, modules and function names). All other files are to be written with all small-case letters, including even readme, license and alike.

Commenting is also standardized, and is described to some extent in Documentation/Template_Subroutine.f90

This issue will be permanently open, and Bojan will take care of it as long as he is alive :-)

Everything goes fine when computation is run in one shot. But once the restart file is used temperature starts decreasing, probably as result of User_Mod_Source function. I modified Source.f90 in User_Mod sub-directory in Process dir, but not in the case directory. Could this somehow be a problem?

Source.f90 is modified as follows:

  !---------------------------------------------------------------------!
  !  Correction of temperature equation with periodic boundary condition! 
  !---------------------------------------------------------------------!
  ! Width of the computational domain
  width = 1.0

  if( phi % name == 'T' ) then
      do m=1,grid % n_materials
        if(bulk(m) % p_drop_x > 1.0e-8.or.&
           bulk(m) % flux_x_o > 1.0e-8) then
          do c = 1, grid % n_cells
            b(c) = b(c) - U % n(c) * heat_flux * width / &
                  (capacity*bulk(m) % flux_x) * grid % vol(c)
          end do
        else if( bulk(m) % p_drop_y > 1.0e-8.or.&
                 bulk(m) % flux_y_o > 1.0e-8) then
            b(c) = b(c) - V % n(c) * heat_flux * width/&
                  (capacity*bulk(m) % flux_y) * grid % vol(c)
        else if( bulk(m) % p_drop_z > 1.0e-8.or.&
                 bulk(m) % flux_z_o > 1.0e-8) then
            b(c) = b(c) - W % n(c) * heat_flux * width/&
                   (capacity*bulk(m) % flux_z) * grid % vol(c)
        end if
      end do
  end if

Dear Egor,

The script you wrote to extract makefile dependencies is a majestic piece of work. Your diligence and prudence in handling the problem is astounding.

Yet, it would be very useful to untie it from T-Flows directory structure. Like: the doesn't know at all about GENE_DIR, PROC_DIR and stuff like that, it simply creates makefile dependencies for the directory in which it is executed from. So, if you are in Divisor, for example, you run ../Utilities/create_makefile_dependencies.sh and "voila" ... you get it right there, just for Divisor.

Would it be difficult to do?

Small issue but important for new users. ROUGH_WALLS is not listed in all_control_keywords. This could be fixed in some of next pushes we will do.

This issue was arose some time ago and it was fixed but somehow it reemerges in the latest version (I did not know if it exists in the version prior to this one). When computing channel flows with periodic boundary conditions, pressure drop printed on screen is imposed one but not calculated one, both for RANS and LES computations. In LES computations of channel flow mass flux that appears in the screen is not the same as the imposed one which should not be.

Z-projection of monitoring plane is zero for some reason. Should be checked.

Dear all,

I think we should remove the branches which we don't use. For example. neu_bux_fix was resolved by me (to my firm belief) and is not just hanging around. The same is probably also true for mhadziabdic-patch-1.

Any advice or opinion would be appreciated.

Information on direction in which the values of inflow variables are defined is now defined in control file. This could be confusing. It is better to move this info into the inflow file itself.

Hi guys,

At present we have two tests for Hybrid model, one on uniform, one for stretched grid. However, it would be very advantageous and convincing if we had many Reynolds numbers. Connected to that, I have some concerns:

1. If we are going to provide cases for a number of Re numbers, what shall we put as data to compare with? I assume some DNS databases, right?
2. If we are going for DNS databases, which would they be? At the time when I was a PhD student there was a database for Re_Tau=180, Re_Tau=590 came a bit later, and after my graduation I also saw Re_Tau=1080. Anything newer and bigger on the market?

Cheers

There is an error in the call to Compute_Momentum (from Main_Pro) which I introduced while Latin America was closer to Africa by one centimeter than it is today 😞

This call:

      ! v velocity component                                                    
      call Compute_Momentum(grid, dt, ini, v,      &                            
                  v % y,     v % x,     v % z,     &                            
                  grid % sy, grid % sx, grid % sz, &                            
                  grid % dy, grid % dx, grid % dz, &                            
                  p % y,     u % y,     w % y)     ! dp/dy, du/dy, dw/dy        

Should read:

      ! v velocity component                                                    
      call Compute_Momentum(grid, dt, ini, v,      &                            
                  v % y,     v % x,     v % z,     &                            
                  grid % sy, grid % sz, grid % sx, &                            
                  grid % dy, grid % dz, grid % dx, &                            
                  p % y,     w % y,     u % y)     ! dp/dy, dw/dy, du/dy        

u and w should be swapped.

In any case, this hardly changes the results in any but Stokes flow cases - which we don't solve. Besides, I fixed in my branch 'algebraic_multigrid_development' so I guess there is no need to react in any way.

issue is simple, but consequences are huge

function Control_Mod_Point_For_Monitoring_Plane looks for a keyword "POINT_FOR_MONITORING_PLANE".
Although all test cases for Process has POINT_FOR_MONITORING_PLANES in control files.

Residuals for pressure correction do not drop as well as number of inner iterations (always stays at maximum number). Temperature equation diverged for some reason. I suspect B.C.

I worked on user function Save_Results.f90 file for channel flow RANS. I finished it but for some reason the file is not called at all. I attached new, debugged function.
Save_Results.f90.gz

I am appreciated that WallDistance for Les/Pipe_Re_Tau_180 case is fine after Divide now, but there are still more problems with it:

1. If you launch Process compiled with "make DEBUG=yes" in Les/Pipe_Re_Tau_180 test case you will get NaN from first time step.

2. User functions for this test case ignore for some reason pipe.1d file and DO NOT produce any output files to compare it with DNS via gnuplot and test_build.sh.

I tried to run case which has 1.2 million cells on laptop with 8 Gb RAM. The computation failed due to lack of memory,
Operating system error: Operating system error: Cannot allocate memory
Allocation would exceed memory limitError termination. Backtrace:
Operating system error: Cannot allocate memory
Allocation would exceed memory limit

But the old version of code run it without error. So it seems that we have problem with the new code. Please help.

Dear all,

I peaked in the github repository from Code Saturne: https://github.com/code-saturne/code_saturne and saw they have a number of keywords in their page. What do you think about it? Shall we do the same? I guess keywords help to get noticed, right?

When performing k-eps-zeta-f in unsteady mode we call it HYBRID_K_EPS_ZETA_F. But when running k-eps in unsteady mode (in the sense to gather statistics) we call it K_EPS and have extra option URANS. Furthermore, for RSM-base models we don't have anything special (if I am not mistaken)

Can we introduce a better consistency here? I would suggest that we have pure models: K_EPS, K_EPS_ZETA_F, HANJALIC_JAKIRLIC and REYNOLDS_STRESS, but if we want to run them in unsteady mode to gather statistics, we add option turbulence_statistiscs .eq. YES

Hence, we would have three options to define turbulence modeling strategy:

• turbulence_model
• turbulence_model_variant currently has many variants, but I would raise it in another issue
  and we also introduce:
• turbulence_statistics
  The latter one could be YES or NO, automatically set to YES for LES, DNS and DES, for others read should be specified from the control file.

Any thoughts, comments or suggestions?

Dear all,

The version of Time_And_Length_Scale which Muhamed fixes recently, crashes when one tries to use RSM. It is because the function uses zeta % n, but it is not allocated for RSM.

Anyone has an idea for a workaround?

Cheers,

Bojan

It seems that, for some reason, user function for channel doesn't work. It is called, but doesn't create the expected result file (result.dat)

Dear guys,

In T-Flows, vorticity is calculated in two subroutines: Calculate_Vorticity and Calculate_Shear_And_Vorticity. I thought that one was too much, but by looking into them, I realized that vorticity is not calculated in the same way in each of these functions 😨

Which one is correct? What shall we do?

Calculation of Twall and heat flux at wall in Update_Boundary_Values.f90 is not correct. I will make corrections and send it for approval.

It seems that restart (nowadays backup) does not write heat flux (t % q) at the wall. It was tested on the channel.

We dropped support for gzip libraries (-lz option) but it's still in Generator's makefile.

I noticed that some files are committed with the comment:

1)

What is that supposed to mean? We have to agree if we are writing understandable comments when committing, or puzzles for fellow developers :-(

write small bash script to extract "use "statements out out .f90 files and turn them into dependencies for make files

Issue appears when you try to save and then load any task like channel with RSM models (HJ).
no stresses or eps are saved

tested on
Tests/Rans/Fuel_Bundle
test case

Subroutine Find_Nearest_Wall_Cell in module Turbulence relies on function Distance. That makes it rather slow, since calculation of distance involves taking a square root n*n times. I believe functionality would be the same if one used Distance_Squared function, which doesn't take square root and would thus be much faster.

Generator: Wall boundary conditions still have to be listed first in order to correctly define boundary conditions. This is not very practical because many new users will not be aware of this limitation.