open TELEMAC-MASCARET The mathematically superior suite of solvers

What is the value of VCUT?
maybe you could add some print directly in the fortran file to obtain the values of FUDRAG and FVDRAG...

Hi

The value of VCUT is 0.1. However, I think the problem lies in, as what you've mentioned before, in the FUDRAG and FVDRAG.

So I printed the FVDRAG and FUDRAG for each IPOIN (There are 10 nodes in the TEC) using this command:

WRITE(LU,*) IPOIN,FUDRAG%R(IPOIN),FVDRAG%R(IPOIN)

and this is the result from iteration 680 to 683:



There is a huge difference in IPOIN=104330, as mentioned in the green square, and when I create a graph listing the value of FUDRAG from iteration 600 to 683, this is what it came up with:



The anomaly happens only for FUDRAG in IPOIN=104330. the FVDRAG and the rest of the IPOINS are all good (I don't know about the jagged lines but it doesn't seem to be a problem).



Does this still mean that the problem occured in the dragfo subroutine?
Thanks a lot.

I think you pointed out the problem...
Values at IPOIN 104330 are significantly higher than in all other points with also a significant increase between iteration 680 and 683 when all other are more or less constant...
The remaining question is how you could reach such values for FUDRAG.
You should examine the formula and values of all components to identify the problem...
Hope this helps

Yes I think that is the problem. This is the equation that I am using.

FVDRAG%R(IPOIN)=FVDRAG%R(IPOIN)-HALFCDSCOSTHETA*UR*ABS(UR)/(AREA(I)*HI*UI)

It is sort of a looping equation and as I have mentioned in the previous few replies, there is no big difference found in terms of values acquired from the dragfo subroutine from the other components. Is it possible that this result happen elsewhere? If I may ask, what other subroutine contains the details about FUDRAG and FVDRAG. Thanks.

I don't think there is other subroutines which could change FUDRAG specifically for this point...

In the same way you trace FUDRAG, try to add all the info on UR, HI, UI ...
There is necessarily something which changes!

Hi,

So, the only thing noticeable that I can find is the value of UI is also very small compared to the other IPOINs.




However, when I see the green line in the first graph below, I don't know whether it is an anomaly or not considering the range of the graph is between 0 and 0.09 m/s.





Other than that, I think all the other values that are components of FUDRAG are all good.

Just to confirm, UI or U%R(IPOIN) means the value of velocity U at that specific IPOIN, am I correct? I wonder why the value is different in that specific point.

Hi
I'm wonder if there is not a problem in the computation of FUDRAG and FVDRAG in fact.
Just to illustrate, lets say we consider a velocity of 1 m/s
FU and FV should vary like the velocity repartition between U and V
But in the code, if U tend to 0 (then V tend to 1) the division by U leads to an increase of FU...

Hello,

I would not better advise you to debug than Christophe. You have succeeded in isolating the problematic lines of your Fortran file.

Your strange value seems to appear when you have rather low velocities (around 1 cm/s or less). That should appear during current reversal when velocity is close to 0. This is not the period of time when tidal current turbines generate electricity or the drag force is significant.

What you can try is to increase the hard coded value 1.D-4 to 1.D-3 (twice for U and V) e.g. or even 1.D-2. You will limit the division by a small value and then a big value for the result in FUDRAG or FVDRAG.

Hope this helps,

Chi-Tuan

Dear Chi-Tuan and Christophe

Thank you for all of your suggestions and guidance. I am forever thankful. I have looked deeper in the last weekend and yes, Chi-Tuan, as you have mentioned it is due to the very small value of velocity that causes the problem (division of a very small velocity value which produces very high FUDRAG value). I added this line:

UI=U%R(IPOIN)
VI=V%R(IPOIN)
IF((UI.GT.0).AND.(VI.LT.0))UI=MAX(UI,1D-3)

Because the error occurs when the velocity is moving southwest and one of the velocities in the node is still moving southeast. So far, I have tried using 1, 3, and 5 turbines in the model and all calculations ran smoothly and produced the results that I need. Should I come across any problem in the future, I will try to reduce the 1D-4 to 1D-2 as you have suggested.

Thank you for your help Chi-Tuan, and also thank you Christophe for patiently helping me debugging this code. I am forever thankful and grateful. Now I can proceed on my thesis. Best of luck for the future.

Greetings from Indonesia,
Michael

Hi

I have a simple question, just out of curiosity.

Anyway, does dragfo subroutine reduces the flow of the current velocity upstream of the turbine due to blockage, or is it only able to reduce the flow downstream of the turbine?

If it is the latter one, is there any module to model the resistance of the flow due to channel blockage?

Thanks