open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello,

I'm trying to use BOUNDARY_COLOUR array in bord.f subroutine. So I modified the last 13th column of my boundary conditions file (I put 999 at every end of lines for instance). I then put a print statement in bord.f in the loop over the boundary points and I have BOUNDARY_COLOUR%I(K)=K instead of BOUNDARY_COLOUR%I(K)=999.

I had a look in leclim.f subroutine and it seems that since v7p1r1 version, BOUNDARY_COLOUR array is not filled with the 13th column of boundary conditions file (KFICH variable in older versions) but with the numbering of these points (by the GET_BND_VALUE_SRF subroutine for the latest versions which does not read the 13th column).

Am I right ? and how should I do to have my own values in BOUNDARY_COLOUR array ?

Sincerely,
Laurent Leballeur

Hello,

You are right, this was pointed out by Pierre Lang also recently. According to him there is now an extra code somewhere replacing boundary_colour by the boundary numbering in scalar mode, which creates a difference in behaviour between scalar and parallel. I'm afraid we have to wait Yoann Audouin's return from holidays to know why this was done and to get a correction. A possible solution inbetween would be to run in parallel. I'll tell you more if I can locate where is this modification.

With best regards,

Jean-Michel Hervouet

Hello Jean-Michel,

Thank you for your reply. I pointed out this problem to P. Lang 2 weeks ago.
Unfortunately, it seems that the problem also happens in parallel mode.

In scalar mode, it's quite easy to modify get_bnd_value_* subroutines and hermes module interface to read an extra parameter.
But in parallel mode, I understand that BOUNDARY_COLOUR array is filled in read_partel_info subroutine by reading the first column of T2DPAR* ascii files written by partel.F. I think that these partel information files are useful for the partitioning stage itself and I'm afraid of modifying this, that can introduce other problems elsewhere.

So I found a solution that consists in reading the boundary condition file twice in leclim.f subroutine and to deal with the renumbering of boundary points in parallel mode to obtain a right BOUNDARY_COLOUR array. I'm aware that the solution is not optimal but it's efficient, and I can't wait too much.

Nevertheless, when I use the T2D_FILES(T2DCLI)%LU channel to read again the boundary condition file, I have an error message saying that
formatted I/O to unit open for unformatted transfers, unit 4, file T2DRES*
I don't understand why there is a confusion with T2DCLI and T2DRES (both in scalar and parallel modes).
When I force the unit channel to read (hard-coded in the code with an arbitrary integer value), it's ok.

Regards,
Laurent Leballeur

Hello,

Yoann is now back and should look at this problem soon. I do not see what is the problem with reading twice the same file, unless a REWIND is missing somewhere, but this should not shift to T2DRES. Try REWIND(T2D_FILES(T2DCLI)%LU) before reading again, but I doubt it culd be this.

With best regards,

Jean-Michel Hervouet

Hello,

Unfortunately, the REWIND command does not change anything.
I am at Yoann's disposal to give him for further details.
leballeur"at"actimar.fr
02.90.26.20.41

Thank you for your help Jean-Michel!

Best regards,
Laurent Leballeur