Denim Umeshkumar Anajwala

Hi Chris,

thanks for your support... It's a real good idea to keep small examples models at hand so that you can check out the effect of modifying a parameter on the modelling results.

bye!

Thomas

Hey Thomas,

I was going to say the default value for porosity is 0.3, but I'm not sure any more. I used one of my small examples and ran particles with the default settings, then set the porosity explicitly under "SET" to 0.3 (and 0.6 / 0.15). A porosity of 0.3 returned very similar results, but not quite the same. You might wanna try this yourself ... I'd say 0.3 is a close enough assumption though.

Cheers, Chris

Hello everyone,

I'm using the 3D particle tracking of FEFLOW (in 3D Options -> Pathlines).

I would like to know what FEFLOW uses as a default porosity value to calculate the travel times.

I know you can specify values for porosity and sorption if you go in the ''SET'' menu related to ''USE ISOCHRON MARKERS''.

However, when I'm not using the isochron markers, I can't figure out what FEFLOW uses as a porosity value to calculate the travel times? This is a problem for me since I exported many tracking results as .DAT files and I'm not sure about the validity of the travel times I obtained.

Note that I'm running a 3D [u]saturated [/u]model and [u]solving for flow only[/u].

Any help appreciated!
Thanks!

Hey Andrés,

I assume your model would be transient and the water table somewhat "well behaved", meaning there is only one (no perched system with more than one free water table at different elevations).

Between time steps, you would have to find that water table, calculate the depth from GS to water table, and then set the boundary condition according to your equation?? The boundary condition would then be assumed to be constant for the next time step. Are parameters A and B constant or variabel over time? They would have to come from an external data source (text file, DB). Is that would you were thinking?

If your FEM isn't too too large, would you mind emailing me a version?

Thanks, Chris

Dear chrisoula,

it is typical for density dependend problems that stability problems occur. To handle this, you have to refine the grid in all 3 directions. Additional a wise time-stepping is necessary. Furtheron you could try upwinding settings.
In my opinion, you should check this first, before you try to find and modify just one element.

Kind regards,
Wolfram

1) From what I understand, the elemental recharge gets aggregated to the nodes based on some sort of "area of influence" (likely a Thiessen polygon). That's ok in general, but introduces a small error to sub-watershed water budgets. Nodes right on the sub-watershed boundary add recharge from the neighbouring elements outside the current sub-watershed! To verify this, compare the sum of recharge of all individual sub-watersheds with the total recharge of the model. The same issue applies to all other BCs on a polygon boundary (luckily, rivers and lakes rarely fall onto a sub-watershed boundary ;D)

2) I had to think about this one for a moment, but it does make sense. If you look at the file documentation (file_formats.pdf), a DAC file is basically the FEM file plus the model results. For a transient run this would be
Ini Cond (as in FEM file) plus
Results TS 1
Results TS 2
Results TS 3
etc ....

For individual TimeSteps, only the results get exported, but not the other model parameters. This is a good thing though, since the DAC file would get really really big for a transient run otherwise. Since you are already working with IFMs, Peter's suggestion is the way to go! Two more thoughts on that:

a) The API function for calculating the flow components (IfmBudgetComponentsQueryFlowAtNode) are SLOW! I normally call them only for nodes that actually have a BC, and avoid the call for nodes with no BCs. The check
IfmGetBcFlowType(pDoc, node) != IfmBC_NO
takes computational time as well, but likely less then IfmBudgetComponentsQueryFlowAtNode. You might wanna check this in your particular situation.

b) Using an IFM module gives you the chance to calculate the recharge to an area more precisely than the water budget functions. Rather than using nodal recharge values, you can use:
elementalRecharge = elementArea * IfmGetMatFlowRechargeValue(pDoc, element)
This overcomes the issue mentioned above (see 1), however, you need to calculate the element area "by hand", since there is no API function available for this (if there is, it's not documented at least)

Fun stuff, Chris

Wow ... that sounds like a bug to me!! The exaggeration should be a purely visual thing, completely independent of the underlying mesh data!!!

Hey Andrés.

To my knowledge there currently isn't an easy way to reference z_WT. It's simply not available as a variable in FeFlow. And it's not that easy of a value to find in the first place (since there might be more than one "water-table" at a given x/y location!).

We developed an IFM module to find the "water-table elevation" and export it to a file for visualisation in a GIS. I would use a similar approach: Write an IFM module to set the evaporation rate based on the water-table elevation, which I'd sear for first. Unfortunately, this doesn't help you much, since I assume you don't wanna go to such an advanced extent as using IFM models/code writing.

Can you explain how your evaporation rate should be calculated and specified in FeFlow (i.e. fnx(z_wt) and the type of BC you plan to use)?!

Chris

[b]Thank you so much Peter

I understood the problem. That comes from the nodal basis calcuation in FEM.
Because I have interests in potential (i.e. head) in many cases. I did not check and think the FEM procedure.

Thank you again [/b] :D :D :D

[size=10pt][b]Thank you so much, Thierry.

I think that you mean that no boundary condition is no flow, i.e. impervious boundary and the vector cross the boundary is just fictitious. Is it right ?

In my question, the VERTICAL means just crossing boundary NOT UP and Down...and I just used 2-D model to test the no boundary condition setting. I am still confused because of the resulting vectors in the boundary which has no boudary conditions.

The sample FEM file (Dynamic_river.fem) has no boundary conditions in left, up and down sides but the boundaries have initial head conditions. Is there any possibility the initial head condition make the boundary as a 1st kind boudary condition ?

Also, if I use the FLUX ANALYZER (in POSTPROCESSOR MENU) to check the in or out flux flow, there are values still in the boundary which was not applied any boundary condition.  I do not understand yet this problem.....Please help me if you (anybody also) know further about this. [/b][/size]