code_saturne User's Forum

Hi,
 
I'm trying to replicate something I was doing in v2.0.1 using memory pointers in v2.1 with the allocable memory.

I have a double precision variable (fd) that is calculated in turbsa.f90 in a loop over ncel (so that fd has a different value at each cell in the domain) and I want to visualise this in ensight. It is defined in a header file using the common syntax.

In v2.0.1 I would use the rdevel memory (allocated in memini) so that in turbsa/kw/ke:

rdevel(ifd+iel-1) = fd 
 
then in usvpst.f90 I would on the volume mesh (ipart=-1)
 
tracel(iloc) = rdevel(ifd+iel-1)
 
Obviously with the rest of the required syntax's etc in usvpst. This worked for me no problem.

I'm trying now to do the same kind of thing in v2.1.

I define fd in optcal.f90 along with some other variables which are used elsewhere. It compiles with the new optcal.f90 (I had problems compiling with custom modules), I don't seem to have any problems with this optcal modification (the cases run etc).

In usvpst.f90 I just set
 
tracel(iloc) = fd
 
I get an output of fd in ensight but its clearly wrong.

I know I'm making a mistake somewhere with the memory but I'm not sure how to do this using dynamic memory.

If someone can help me out that would be great, so I know the procedure.

Thanks very much

Neil

Hello Neil,

Did you allocate fd on the first pass, and did you declare it as "save" ?

In any case, I do not recommend modifying optcal or any other non-use module, unless you recompile the whole code. It is probably not as unsafe as modifying the previous common blocks, but behavior may be compiler dependent.

I would rather recommend solving the compilation problems you have with user modules (i.e. post the compile.log and and user module if you need help), rather than modifying the base code for any other purpose than full development work (in which case rebuilding the whole modified code is the standard practice).

Best regards,

  Yvan

Hi Yvan,

I didn't allocate it but I did declare it as save in optcal. However I agree with you that it is better to try and fix the user modules than recompile the code (which is what I currently do) and then move onto the problem of allocating values.

I've attached the subroutines and compil.log file. As you can see, I have a module file inchyb.f90 which cannot be found by usini1,turbsa etc even though it is clearly there. The only way I could get round this problem was by changing optcal directly in its src folder and then reinstalling the code. There is another module file, incthi.f90 which works no problem. It seems to only affect some subroutines, so I think it might be something to do with the order of compilation.

I'm also not sure how to allocate fd so that a value is updated at every cell for each time step and then pasted to usvpst (and also to the bilsc2.f90 subroutine).

Your help would be greatly appreciated!

Thanks

Neil

Hello Neil,

You do need to allocate fd (for example at the first time step). Depending on the compiler, declaring it as save may be necessary or not, sot it is a safe bet to do it for safety.

Once allocated in a module and declared as save, just update fd(iel) values in turbsa and use the array in usvpst.

In your example, fd soes not seem to be an array, but just a scalar, so I am not sure this is the value you want.

Regarding your problem with modules, compilation order is essential. That is why you will find a user_modules.f90 file, in which you may define any user modules, and which is compiled first.

You can simply rename inchyb.f90 to user_modules.f90 (without changing its contents), and things should work. You may have several modules defined in the same file, so if a given module is named inchyb, the calling code will need "use inchyb", and not "use user_modules" (i.e. the name of the file itself is only important regarding compilation order, not regarding its contents).

Still, you may want to check the module examples in users/base/user_modules.f90 for examples of user allocatable arrays.

Best regards,

  Yvan

Note:
actually, for user_modules.f90 to work as advertised, you should not change its name, but you may still define anything you want within that module.

Hi Yvan,

Thanks very much for explaining the new way of dealing with modules. It now successfully compiles, however I have a memory violation error which I think is down to me not allocating it correctly. If you could have a quick look that would be great.

Just to test, I tried to allocate and deallocate the array's in turbsa.f90 directly and print out their values (just for turbsa.f90) and it does what I want it do to, however I obviously need it in a module because I want those values to be used in different subroutines.

As you can see in the attached subroutines, I define two array's in user_modules.f90

Then I allocate it in the same module when (ntmabs.eq.ntpabs+1) and then deallocate it when (ntmabs.eq.ntcabs).

I realise I must be doing something wrong but I wasn't sure when and where I should do the allocating because I don't know if user_modules.f90 is read last or first, i.e I don't want it deallocating before I use usvpst.f90 on the last time step for example.

Thanks very much

Neil

Hi Neil,

You need to call init_user_module explicitely somewhere before using the arrays, so your error is probably due to this (so the test on ntmabs could be done outside the module).

Finalizing it is less important: if you are checking for memory leaks with a tool such as Valgrind and do not call finalize, you will see a memory leak, but as it occurs after the time loop (just before the code exits), it is harmless.

Alternatively, you may simply avoid defining init_user_modules  and finalize_user_modules, and simply declare the arrays in the module. In this case, allocate an array before writing to it (checking if it is already allocated to avoid issues), in the subroutine that sets its value, and use it as any other array in other subroutines (requiring a "use user_modules" in both cases).

Best regards,

  Yvan