Denim Umeshkumar Anajwala

This is an excellent comment!!! I was wondering about this exact same thing recently, when I was using a PreSimulation IFM to update K data. If I understand the process correctly, this is how FeFlow generates a DAC file:

1) Copy data (incl. K's) from FEM to DAC file
2) Run simulation (next time step)
3) APPEND simulated heads (and velo's) to the DAC file
    (for those time steps specified)

That should explain why K-data manipulated through an IFM during the simulation is not stored in the DAC file. Only simulated heads get appended to the DAC. Correct?

[Edited: Ops, I just noticed that I had made a similar comment before under "IfmBudgetComponents - area flux"  ;D]

Now I'm wondering: Is it possible in FeFlow to specify time-varying K data? I've never tried that (and can't really think about a reason why I ever would), but a quick peek at the FeFlow help suggests, that this is possible by either using a T-List or power-functions. How would that be reflected in the DAC file and how would the Budget Analyzer consider this time-varying K-data in it's computations? ???

Chris

Hey Rouven,

those fluxes should indeed be the same. If you model isn't too big, feel free to email it to me with the code and I'll have a look at it.

Cheers, Chris

Dear George,

it is of course possible to run FEFLOW interactively using an IFM module. However, for a start it might be easier to use PEST or FE-LM2, depending on your needs. The latter is directly integrated into FEFLOW and accessible via the tools menu entry (Start parameter fitting ...). A lot of additional details are given in the FEFLOW documentation. PEST has to be loaded as an IFM module.

Kind regards,
Wolfram

Hey William!

You just got me really confused about layers and slices and data attached to them :D Here is how I think about it - and I'd say that's how FeFlow stores and uses it:

Some data are specified at nodes, that is on the slices. Other data however are specified for elements, which make up the layers. To give some examples: Heads and elevations are nodal data; they are specified for each node on each slice. Material properties, such as Ks for example, are elemental values and specified for each element on each layer. So you're really dealing with data at different "locations in (a 3D) space".

For calculating transmissivity, you need to combine an elemental property (K) with a nodal property (thickness) - I call thickness a nodal property here, since it's calculated as the difference between nodes on two slices. In order to accomplish that, you need indeed some averaging somewhere. The way you described in you post uses average Ks at nodes.

I didn't even know one can export Ks at nodes. But I just tried it (Special - Save nodal materials as Points) and find that very "interesting", because of the way the averaging is done. If Ks vary only from one layer to the next, it's simple the average between the 2, which is fine I guess. However, if Ks vary within a layer itself, then the average is basically
  the sum of Ks of all attached elements
  divided by
  the number of attached element of that node.
Is that a proper average??? I'm  not sure  :-\

Personally, I prefer to think about transmissivity as another elemental property. Therefore I compute transmissivity by multiplying the elemental K with an average element thickness, which I approximate by taking the average of the thickness at the (3) nodes defining the element. Whether that average is better might be questioned, but I find it definitely more intuitive.

Here is how I do it:
1) Export Ks as a "mesh" polygons (Flow Materials - Special - K - Isolines - Elements)
2) Export layer thickness as points (3 D slice elevation - Special - Z - select Thickness - Points)
3) Overlay both in my GIS
4) Calculate the average elemental thickness from the nodes attached to an element and
    propagate the result to the elements
5) Calculate the transmissivity = K x averageElementThickness

You have to do that for each layer separately and step 4) depends on your GIS (in Manifold it's a simple spatial overlay with transfer rule set to n->1:average). You can show the transmissivity then by applying a colour scheme to the polygons. And voila! You're done :)

A lot easier and faster yet is using an IFM. But that's a completely different story  :)

Hope that helps, Chris.

Never used it, but curious to find out! Chris

Faby,

if you already have a shape file, why don't you use that for the join? You can do a join with a shape file just as well. Open your existing elevation shape file in your GIS, adjust it as needed, add a field for the K data, export it as a new shape file and use it in your join to set the Ks in FeFlow. That seems a lot easier (and more straight-forward) than using ply files. Either way, you need to manipulate the DBF file, since that's where the data is eventually taken from.  For working with shape files you'll need a GIS (I recommend Manifold GIS because it's very powerful, user friendly, and inexpensive!). The DBF is part of your shape file (which is really 3 files: shp, shx, dbf), so once you export your modified shape file with the K data, your dbf will be up-to-date automatically.

Good luck, Chris

Hi All!

i know that currently, papers about hydrological models are generally
expected to use PEST also. for other models in geo-science or other scienses it
is not the general requirement.

[color=teal][size=14pt][color=purple][b]i wonder what is the general opinion of the forum members? [/b][/color][/size][/color]does PEST improve the model adequacy? or it just give the modeler a hard time?
do you think what good for a lab model, or a field test is also good for regional models?

please express yourself freely!

William,

that's a tough one. FeFlow is currently available in version 5.305. If this is a known bug, it's pretty much guaranteed to be fixed by now (in version 5.3 that is). You could go through the bug lists at
[url=http://www.wasy.de/english/products/feflow/download_ov.html]http://www.wasy.de/english/products/feflow/download_ov.html[/url]
and check if this was fixed in a patch or newer release and update your software accordingly.

Sorry, for not being of more help ... Chris

Hey Eladd,

thanks for the example.
Too bad my browser screws up some of the characters ( : I think those are supposed to be tabs?)  :(
Also in the last line of your post, it should say
[b][i][...] will [...] create a .ply file in the same directory and in the same name, i.e. polyg3.ply[/i][/b]
Just a typo :)

As a side note: If your PATH variable contains the path to FeFlow, you command can be truncated to:
[b][i]shptoasc d:\feflow\north\gisdata\polyg3.shp id[/i][/b]

So I checked out shptoasc, and option -d caught my attention. I compared the ply file generated with and without that option. The difference is a section at the end of the file, that defines the linkage to the data in the dbf file (see attachement). It gives you a template and instructions how to modify it. I followed those, but when I tried to join the ply file, it still would recognize the linkage. It popped up the "Item-Parameter Assaciation" dialog. Once you specify the links, it will join the data and save a ffi file. The ffi file looks pretty much the same as the "link section" in the ply file:

[i][b][Join]
DATABASE kZones.dbf
TYPE DBASE
ITEM ID ID
ITEM KX CONDX[/b][/i]

Bottom line is: I don't know why the modified ply file doesn't work, but I figure one could generate ffi files easily since they follow a simple scheme - Faby was asking about that in a different posting ("Polygon file").

Any other ideas on this?

Chris

Hey Faby,

what are you trying to do? It sounds like using a shape file would be a lot easier than a polygon file. Do you use a GIS that can export data to shape files? Shape files store both the geometric information (shape of the polygon) and the assigned attributes (in a linked dbf file).

If you are trying to join or assign data to conductivities, shape files will likely make your life a lot easier.

Oh ... I just re-read your original posting. PEST ... mh .. I would have to check if PEST can use shape files at all.

Chris