Denim Umeshkumar Anajwala

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

No reason except that I typed before I thought.  If the goal is to just get node coordinates, either will work. Exporting nodal data at nodes has the added benefit of obtaining node data as well as node coordinates. When exporting material properties, I export as elements and also save the element coordinate information.

Hey Dwaine,

quick question: Why do you suggest exporting elemental data at nodes, rather than exporting nodal data such has elevations or heads? Any particular reasoning for that?

MapWindows looks interesting. I just had a look at Leszek Pawlowicz's introductory videos at
[url=http://freegeographytools.com/2007/introduction-to-mapwindow-gis-i-shapefile-viewing]http://freegeographytools.com/2007/introduction-to-mapwindow-gis-i-shapefile-viewing[/url]
Pretty cool!

Cheers, Chris

There is a mesh inspector within the mesh geometry editor, but it does not give coodinates  :(  (a new feature to consider?)

If accuracy is not an issue, I usually just zoom way in onto a node and read the coordinates while using the magnifier tool. Otherwise, I usually export the node information by using Flow Materials ... Special ... Save Nodeal Materials as Points. This gets me a list of nude numbers and their coordinates which I can then import into Excel.

For GIS software, we use MapWindow (www.MapWindow.org). It's free.

Dwaine