corrupt 1D Fracture element (e = ...)

Hi,

I am simulating a network of underground mine galeries, with the 1D element option of Feflow. When running the model a log message appears (that doesn't prevent to run the model):
WARNING: Corrupt 1D fracture element (e = 748) found. Deletion
So if I understand the 1D element n°748 is not taken into account (deletion) in the run. I have the same message for a couple more elements.

How can I find the element that causes this warning ? I don't find a way to export the 1D elements with their ID, or to display those ID in Feflow. Also what usually create those warning ? Location, element parameters ?

My elements are crossing each others sometime. Is this alllowed ?

Cheers !
Didier

Hi Didier,

Crossing arbitrary discrete elements are allowed.

The only option for finding those corrupt elements is using the mesh inspector, since it is the only way to display the elements number.

Another additionial workaround: Delete all DFE's from the top to the middle slice and run the model. Do the same again for the lower half of slices. For each run, observe which elements are causing errors. You can intensify the procedure by using it for each slice. This way you should be able to localise the corrupt elements, at least you know then on which slice they are.

Thanks Bastian !
Another question related to the discrete elements. I am simulation channels on slice 1, with the Manning Strickler 1D element. I can't find the way to make sure that my element only drains the aquifer and doesn't feed it. Or/ is there a way to only allow water to get into the element ?

Cheers,
Didier

I did some tests with a small symbolic model and finally ... I am confused. It seems like using the 3Rd type bndry and the in or out transfer rate, we can easilly decide if the boundary feeds or drains or can do both. But the same options with the 1D element appear to be useless. The default values for in and out in discrete elements are 0, nonetheless the elements seem to work with such and the result is not sensitive to whichever value you assign. :-\

You can get a listing of the DF by saving the FEM in ASCII and searching the file using a text editor for "FRACTURES".  See the pdf supplied with FEFLOW called "file formats.pdf".  The DF are listed sequentially starting with element 1 and there are two sections of information, node connections and properties.  It is quite possible that there is an error in you mesh that is causing the problem.  Perhaps overlapping elements.

The transfer rate properties are averaged just like other properties, thus setting one to zero will not stop flow.  The only way to ensure strictly flow in or flow out with 1st and 3rd BC is to use constraints. 

Thanks Pete,

When saying "properties are averaged" that is obscur to me. If all the values are set to 0 (e.g. the IN or the OUT flow properties), then the average should be 0, isn't it ?

Cheers !
Didier

If in and out transfer rates are set to 0, and the budget analyzer still shows flow, then the reason is the following: The budget analyzer calculates the boundary flow at locations with boundary conditions - thus including nodes with a transfer BC and 0 transfer rates. To get the flow, it solves the flow equation backwards, i.e., it uses the resulting hydraulic heads and calculates the sink/source term from them. Now as we all know the solution is never perfect - depending on the error criterion we have chosen we might have hydraulic heads that do not perfectly fulfill the conditions of the flow equation. This means that even with a boundary flow 0 used for the forward calculation, the backward calculation may show some boundary flow. Conductivities in the discrete element are typically very high, so even from a small remaining error in head a relatively large flow may result. To reduce this error, you may use a stricter error criterion, either by lowering the error tolerance or - if this only concerns a small number of nodes - by using a maximum norm.

On the other hand, some averaging may be involved in the use of transfer rates may occur (but not with 0 for in and out): FEFLOW has to decide whether the flow is 'in' or 'out' - which is known on a nodal basis. Transfer rates are defined on an elemental basis (except for discrete elements). If we look at two neighboring nodes, and one shows inflow, one outflow, then for the elements in between only one transfer rate is used. If the average condition is 'in' then the in-transfer rate is mapped to the equation for both nodes and vice versa. Therefore locally it may happen that there is a little bit of inflow at certain nodes even if the transfer rate is set to 0. In these cases, a constraint has to be applied.