IfmBudgetComponents - area flux

Hello,

I'd like to save a spatial and temporal distributed budget (especially the area flux from recharge) during a simulation. Looking at the IFM help files I found out that there is a function IfmBudgetComponentsQueryFlowAtNode() which gives back the budget values for every time step if called in PostTimestep().  Up to now I thought that an area flux is related to an element (triangle) in FEFLOW, not with a node. But IfmBudgetComponentsQueryFlowAtNode() computes the flux for a node. What is the correct meaning of this flux?

A second question: I use an IFM module to change the groundwater recharge (inflow on top) for the elements of the first slice of a 3D model over a time period by calling IfmSetMatFlowRechargeValue(). After simulation the budget analyzer does not reflect the change in recharge, the fluxes are constant for all time steps. Is there a problem in the budget analyzer or do I have to use an other function for setting the recharge?

Thanks

Torsten

1) Recharge is set as a parameter to elements. However, the calculation in a finite element model is node-based. The recharge therefore is entering the model in the nodes, no matter whether it is defined using a Neumann boundary condition or in/outflow on top.

2) Material properties changed via IFM during the simulation are not reflected in the dac file. Therefore the budget analyzer does not know about the changes and will return a budget based on the original values. You'd have to use the budget functions in IFM to get the correct water balance for the entire simulation time.

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

As an update: I talked to the FeFlow developers: there is currently no API function available to return the "area of an element"  :(

It's on my wish list though ... Chris

Hi Chris

Its fairly easy to calculate the area of an triangular element from the nodal coordinates. I can give you the equation if you need it.

Thanks Panos,

I can't remember of the top of my head, but I'm pretty sure I implemented that by now ....

Thanks, Chris