open TELEMAC-MASCARET The mathematically superior suite of solvers

After finding problems with evaporation causing bad geometry in nearly dry areas, the supplied fixes have resulted in lots of code changes. So it was going to be a headache to try and patch the changes into the v7p1r1 version.

Because of this I have needed to compile up the trunk version of the code (checked out 30 Nov.) To incorporate atmosphereic exchange (which is now coded in the waqtel module), I now need to configure the waqtel module.

I have coupled with waqtel, I have created a waqtel cas file with ATMOSPHERE-WATER EXCHANGE MODEL = 1. But how do i specify that I want to use atmospheric exchange (only).

I get the following error..

INCREASE_NTRAC: UNKNOWN WAQ MODULE : 0

So how do I specify a WAQ MODULE?

PS I also had problems getting partel to work completely - error was in splitting 'other files' and in particular processing the waqtel cas file.

Cheers
John

Got the waqtel module accepted now but for some reason telemac3d is dying at line ~724 in telemac3d.f with invalid memory reference. This line is

IF(NTRAC.GT.0) CALL OS ('X=Y ', X=TRN, Y=TA)

I cannot even print out the value of TA using

print *,'JMF telemac3d TA ',ntrac,i,TA%ADR(I)%P%R(1:10)

without the print (before the X=Y call) it crashes in CMPOBJ call.

Yet TA is initialised in condim using

CALL OS( 'X=C ' ,X=TA%ADR(I)%P,C=TRAC0(I))


Very strange. To check the problem I have reverted to a single processor mode. Normally running in MPI! Have been running dbg versions for line info. Done a compile clean.

Previous version v7p1r1 working well on same compiler - all linux based.

john

Didnt mention - I am loading a hotstart file. This appears to be the problem.

If I disable the COMPUTATION CONTINUED, then it runs. I think the only READ_DATASET is activated by this.q

I will try to recreate the hotstart file and see if that changes things.

Even stranger things trying to run the warmup - now running MPI, reports that preconditioner 17 is matrix is badly conditioned. However I have not defined preconditioner 17 or 34 anywhere ....

Hello

This is a bit strange. To start properly, you can just adapt the case heat_excahnge in the examples/telemac3D folder. This folder is an up-to-date version of old heat_exchange case.

If it dosn't run, please send us you case.

with my kind regards

Riadh

Riadh,

Thanks for that. I ran the heat_exchange example in telemac3d as you suggested, and it appears to run ok. So not a lot of help.

I have run a few other options on my model setup and it is definitely linked to READ_DATASET. If I remove CONTINUED CALCULATION settings, it runs with no memory problems.

I found a few other problems along the way - eg the detect endian code in hermes, does not like symbolic links in linux ... I have fully checked the meteo code that I use - needed changes to due to the new waq changes. I also did not have the geo file and boundary file declared in the waq cas file - I thought they would have been transferred internally. These let me get a run going without memory problems.

John

Some extra info ....

if I put the following print before and after the read_dataset call (arond line 635 in telemac3d.f)

print *,'JMF telemac3d TA 1 ',TA%ADR(1)%P%R(1:10)

the memory corruption occurs at the second print after the READ_DATASET .... when it tries to access the TA variable.

I still cant isolate what is happening here. The one specific thing about my case is that the hotstart runs with no tracers calculated or stored in the hotstart file. This allows me to set uniform start conditions for temperature and salinity. The hermes read utilities do pick this up generating an variable unknown status result which should result in nothing being written to memory.

John

More info.

At these print locations, I can obtain the names eg
TA%NAME

it appears that access to the pointer TA%ADR(i)%P that causes the error.

It is starting to look like a memory overwrite from somewhere else.

I dont think it is a compiler internal error as v7p1r1 compiles and runs well.

I think I have found it. READ_DATSAET memory corruption occurs due to bad array size passing to get_data_value. Memory checks dont work because get_data_value redfines the array with NPOIN_PREV size.

VARSO3 allocates some variables with DIM1=0 (if hydrostatic calc). See point_telemac3d.

However the get_data_value call in read_dataset passes the size of the array as NPOIN_PREV regardless of the array allocated size. This overwites memory. The compiler in debug mode does not pick this up possibly because pointers are used!?

This error sometimes shows itself - sometimes not. It may explain some strange behaviours that I could not explain.

Either use the DIM1 value for the variable or skip the read if dim1 is zero. Not sure how using dim1 effects the interpolation system so the safest approach is to skip the read if dim1==0.

Thanks Riadh.

I ran the telemac3d heat exchange example. There were no problems,

So I tried a few more vaiations on my own case. This shows that the memory corruptions errors arise due to READ_DATASET() calls when using the CONTINUED CALCULATION option. Still have not isolated these.

Found a few errors in my setup doing this. I had not specified the waq geom file or boundary file, thinking that this info would be passed through the system. I suppose it allows the different grids to be used for each system. This also showed that the check_endian routines dont like symbolic links on linux with the gnu fortran compiler. I also needed to ensure that my use of bord3d and meteo user defined fortran code agreed with the new interfaces and variables.

John