Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1
  • 2

TOPIC: Accumulation at inlet with no sediment influx

Accumulation at inlet with no sediment influx 1 year 9 months ago #41903

  • Renault
  • Renault's Avatar
  • NOW ONLINE
  • Senior Boarder
  • Posts: 120
  • Thank you received: 33
Hi all,

I have run into a perplexing issue that runs counter to what I would've expected. In essence, I'm trying to determine the armoured GSD from a known, pre-armoured GSD and so I'm running the model without any sediment input (fluxes = 0.,0.). I am using GAIA, Wilcock and Crowe, and bedload only for this simulation. My GSD runs from over 56 mm to under 1 mm (gravel stream).

My problem is that the bed at the inlet boundary is beginning to rise in ripples perpendicular to the flow direction. This accumulation is on the order of 7 cm in 35 minutes. This doesn't sound like much, but it does cause a numerical instability problem where at the scale of my model (flow depth ≤ 30 cm), it causes supercritical inflow and since I don't have an H at the inlet, it halt-and-catch-fires. Obviously, I could bandage the model by setting a known H, but this only moves the problem back a step.

Fundamentally, what I don't understand is why would the bed rise, and why would sediment build up, at the inlet when there is no sediment influx? I would expect the opposite - scouring at the inlet - rather than a buildup. Maybe I'm missing something obvious, but this makes no physical sense to me. I have checked the cumulative bed evolution on the boundary itself and it is > 0 cm, so it's not digging downward on the boundary to accumulate sediment at the next nodes.

Could it be worth it to try with a different set of equations? W&C seems most suitable to my application, so I'd rather not try others for now, but I can try MP&M as well.

I have attached a screenshot of the phenomenon as well as my steering files (apologies for the mess; I have no idea how best to structure a .cas). If needed, I can provide .cli and .slf, but I'd prefer not to if possible.

Thanks for any insight on why GAIA would accumulate sediment!

André Renault
Attachments:
The administrator has disabled public write access.

Accumulation at inlet with no sediment influx 1 year 9 months ago #41909

  • Renault
  • Renault's Avatar
  • NOW ONLINE
  • Senior Boarder
  • Posts: 120
  • Thank you received: 33
Hi all,

Apologies for the double post. I tried with an influx of 8 kg/min (0.1375 kg/s) and this time, the same conditions (accumulation of 7 cm, supercritical crash) were observed after 55 minutes of simulation time instead of 37 minutes. This is most perplexing...
The administrator has disabled public write access.

Accumulation at inlet with no sediment influx 1 year 9 months ago #41919

  • kopmann
  • kopmann's Avatar
  • OFFLINE
  • Senior Boarder
  • Posts: 106
  • Thank you received: 65
Dear André,

how did you set your open inlet boundary (one line from the cli-file would be enough)?
What happens to the open boundary nodes. Is there an accumulation? From the file I would think there is no evolution directly at the boundary. What about the shear stress at the boundary? Is it high enough that the sediments should move?

Two ideas to smooth instable results especially at the boundaries:
You can try FINITE VOLUMES = YES and play around with upwind criteria (UPWINDING FOR BEDLOAD default is 0.5. If you use up to 1.0 it is more diffusive but also more stable.

Furthermore sometimes it can be helpful to start with a rigid bed at the inflow boundary. Typically, this also smoothes results because it decouples the morphodynamics from the hydrodynamics for the uncertain boundary part.

Best regards,
Rebekka
The administrator has disabled public write access.

Accumulation at inlet with no sediment influx 1 year 9 months ago #41921

  • Renault
  • Renault's Avatar
  • NOW ONLINE
  • Senior Boarder
  • Posts: 120
  • Thank you received: 33
Hi Rebekka,

Thanks for your reply with many avenues to pursue!
I will try the FINITE VOLUMES / UPWINDING FOR BEDLOAD keywords to begin with for sure. This will take a while to run, assuming it does run to begin with :laugh:
For the rigid bed, would I have to look into creating my own noerod.f or is there a way to define these areas in the .slf (eg. Blue Kenue)? If the former, which examples would be best to look at, if you know of any in particular?

For shear stress on the upstream boundary, it ranges from 13 to 16 N/m2 which is plenty to move this granulometry. Cumulative bed evolution on the upstream boundary ranges from 0 to 18 mm upwards; as mentioned, nodes 1–2 rows from downstream reach 70 mm.

Here are two lines from my .cli file, one for a downstream BC and one for a closed node:
5 4 4  0.000 0.000 0.000 0.000  4  0.000 0.000 0.000           1           1   # downstream (689 - 1)
2 2 2  0.000 0.000 0.000 0.000  2  0.000 0.000 0.000          11           2   # 
I modified it as per this article.

Thank you again for your helpful advice!
André
The administrator has disabled public write access.

Accumulation at inlet with no sediment influx 1 year 9 months ago #41932

  • kopmann
  • kopmann's Avatar
  • OFFLINE
  • Senior Boarder
  • Posts: 106
  • Thank you received: 65
Hi André,

for the upstream boundary in gaia and a prescribed solid discharge you need 1.0 in the 4th column. I didn't see that in the website you refer to. But maybe I just did not found it. (see validation example flume_bc-t2d)
4 5 5 1.0 0.0 0.0 0.0 4

In gaia there is no noerod.f anymore. You can define the rigid bed by the layer thickness(es). If all layer-thicknesses are zero then you have a rigid bed. You can do this in user_bed_init.f (see the hippodrom-t2d validation test case).
Or you create a previous sedimentological computation file and changes the active layer thicknesses via blue-kenue.

Best regards,
Rebekka
The administrator has disabled public write access.

Accumulation at inlet with no sediment influx 1 year 9 months ago #41934

  • Renault
  • Renault's Avatar
  • NOW ONLINE
  • Senior Boarder
  • Posts: 120
  • Thank you received: 33
Hi again,

Thanks for these ideas, I have adjusted my .cli accordingly. Someday I will understand the CONLIM structure :laugh:

A few updates.
First, I tried the FINITE VOLUMES / UPWINDING FOR BEDLOAD with values of 0.50, 0.75, and 1.00 for the latter keyword. The 0.50 completed a 1h00 simulation, and the 0.75 and 1.00 both failed after just under 0h30 of simulated time. Moreover, all simulations still have rippling at the inlet, and the rippling is somehow more pronounced than it was! That is to say, it seems to propagate further downstream...

Now, I am trying to make the first metre or so non-erodible to see if this will work. Unfortunately, this is turning out to be more complicated than I thought (and it looked complicated already!). I grabbed a list of elements from the mesh that I wanted to make non-erodible, put them in a text file, and tried reading the file as part of user_bed_init.f (attached).

I have debugged a few points already, including the need to manually copy the noerod.csv into the working directory (scratch directory on an HPC cluster) and apparently needing to transform points from global to local (I was getting segfaults if I just fed it the following).
! DO loop here where I feed it a node number IPOIN
            ESTRATUM(1,IPOIN) = 10000.D0
! loop...

It should be noted that I am doing this computation in parallel, as it is a rather heavy simulation and I am not sure how to run only the user_bed_init step in series.
My latest problem is at the compilation stage. Here is the relevant code:
OPEN(UNIT=10, FILE="noerod.csv", STATUS="old", ACTION="read")
      DO
            READ(10,*,END=99) IPOIN
            ESTRATUM(1,GLOBAL_TO_LOCAL_POINT(IPOIN,MESH)) = 0.D0
      END DO
99    CONTINUE
! close the file, return, etc.
This apparently leads to memory errors and I'm not sure why; at this stage, the errors become:
================================================================================
 ITERATION        0    TIME:   0.0000 S
 PRERES: MAXIMUM COURANT NUMBER:    0.1021956

                            BALANCE OF OMEGA (UNIT: NA * M3)
     INITIAL QUANTITY OF TRACER   :    0.000000
 TELEMAC2D COUPLED WITH:
 GAIA

 TELEMAC-2D: INTERNAL COUPLING WITH GAIA
 INBIEF (BIEF): NOT A VECTOR MACHINE (ACCORDING TO YOUR DATA)

 LIQUID BOUNDARIES:           2

free(): invalid pointer                    GAIA INITIAL MASS OF SEDIMENTS:

 TOTAL MASS OF CLASS  1 =    2629.891    ( KG )
 TOTAL MASS OF CLASS  2 =    840.7029    ( KG )
 TOTAL MASS OF CLASS  3 =    2910.125    ( KG )
 TOTAL MASS OF CLASS  4 =    2220.318    ( KG )
 TOTAL MASS OF CLASS  5 =    1767.632    ( KG )
 TOTAL MASS OF CLASS  6 =    711.3640    ( KG )
 TOTAL MASS OF CLASS  7 =    603.5815    ( KG )
 TOTAL MASS OF CLASS  8 =    1530.510    ( KG )
 TOTAL MASS OF CLASS  9 =    1853.858    ( KG )
 TOTAL MASS OF CLASS 10 =    6488.501    ( KG )
free(): invalid pointer
free(): invalid pointer
free(): invalid pointer
free(): invalid pointer
free(): invalid pointer
free(): invalid pointer
free(): invalid pointer
free(): invalid pointer (and so on and so forth)

I realize this is now a Fortran question rather than a GAIA question, but how can I get this code working, especially with parallelization? Or can just this subroutine be run in serial? Would it be better to somehow import all the points in noerod.csv into user_bed_init.f? I have attached the full user_bed_init.f file.

The previous computation file sounds like an interesting option, but in my mind it would still be simpler to have that as part of the geometry variables in the .slf object :) Maybe I will try this, run just one time step and then use the output as previous computation.

Again, thank you so much for your help!
André
Attachments:
The administrator has disabled public write access.

Accumulation at inlet with no sediment influx 1 year 9 months ago #41937

  • c.coulet
  • c.coulet's Avatar
  • OFFLINE
  • Moderator
  • Posts: 3722
  • Thank you received: 1031
Hi
You should read the telemac user manual on input/output files and use available keyword to manage correctly the copy/partition of user files and then avoid management of opening/close (see formated file 1 ...)
Christophe
The administrator has disabled public write access.

Accumulation at inlet with no sediment influx 1 year 9 months ago #41941

  • Renault
  • Renault's Avatar
  • NOW ONLINE
  • Senior Boarder
  • Posts: 120
  • Thank you received: 33
Hi Christophe,

Thanks for these hints. Based on the user and reference manual as well as the developer guide, I tried changing my code in user_bed_init.f to the following, as well as using the FORMATTED DATA FILE 1 keyword in the .cas file:
DO
         READ(T2D_FILES(T2DFO1)%LU,END=99) IPOIN
         ESTRATUM(1,GLOBAL_TO_LOCAL_POINT(IPOIN,MESH)) = 0.D0
      END DO
99    CONTINUE

However, at runtime, it gave an error for every thread:
forrtl: severe (256): unformatted I/O to unit open for formatted transfers, unit 13
It sounds like the FORMATTED keyword is, for want of a better term, creating unrealistic expectations for what the I/O is supposed to see. As a reminder, my input file is simply a newline-separated list of integers referring to node IDs (Unix format on Unix machine), nothing else.

Since this failed, I tried the BINARY DATA FILE 1 keyword instead with BINARY DATA FILE 1 FORMAT set to 'BIN' since this is listed as an option in the T2D v8p4 reference manual. However, this gave a PLANTE(2) saying there are only 3 options (SERAFIN, SERAFIND, MED). It would appear there is a small discrepancy between the reference manual and the state of the code... so I have gone back to trying with FORMATTED instead.

Anyway, maybe I shouldn't be trying any of this, as I am very much inexperienced with Fortran and the Telemac architecture hanging over what seems to me to simple operations. However, it seems to be the only "true" way so far to create a spatially heterogeneous active layer thickness (which occurs quite frequently in nature!), and I have really struggled to find any examples of a successful GAIA case where a file is read in parallel without errors.

Further advice is therefore most welcome, although I will certainly continue hacking away in the meantime to try and get this working. When I do, I will document it as breadcrumbs for the next poor soul trying this :silly:

Thanks,
André
The administrator has disabled public write access.

Accumulation at inlet with no sediment influx 1 year 9 months ago #41942

  • c.coulet
  • c.coulet's Avatar
  • OFFLINE
  • Moderator
  • Posts: 3722
  • Thank you received: 1031
Hi
You could try a dos2unix for the formatted file ...
Otherwise, you could have a look at the telemac2d pluie testcase particularly those with cn_geo.
THe cn value is directly implemented in the geometry file so the code is adapted to cope with such data.
Hope this helps
Christophe
The administrator has disabled public write access.

Accumulation at inlet with no sediment influx 1 year 9 months ago #41943

  • kopmann
  • kopmann's Avatar
  • OFFLINE
  • Senior Boarder
  • Posts: 106
  • Thank you received: 65
Hi André,

in case you skip the fortran definition you can also try using a PREVIOUS SEDIMENTOLOGICAL COMPUTATION FILE. Just run your simulation only 1 time step and create a gaia-result file which should contain all layer thicknesses. Then you can set the layer thicknesses near the inlet to zero via blueKenue (I hope this is possible). Afterwards you start from that prev. sed. computation file.

Another idea we do sometimes is to set a special roughness coefficient (e.g. 0.0301 instead of 0.0300 otherwise which would not disturb your hydrodynamics, CHESTR is the roughness coefficient in telemac, you can include it in your subroutine by the "USE" command) near the inlet. Then the coding in user_bed_init is more easy:

USE DECLARATIONS_TELEMAC2D, ONLY : CHESTR
...
DO I=1,NPOIN
IF (ABS(CHESTR%R(I)-0.0301).LT.0.000001) THEN
ESTRATUM(1,I) = 0.D0
ESTRATUM(2,I) = 0.D0
ENDIF
END DO

Best regards,
Rebekka
The administrator has disabled public write access.
The following user(s) said Thank You: Renault
  • Page:
  • 1
  • 2
Moderators: Pablo, pavans

The open TELEMAC-MASCARET template for Joomla!2.5, the HTML 4 version.