-
Thanks for reporting!
Regarding to Bug #1, this somehow happens in the following situation: 1) a new param. definition is created as "one layer adjustable and other tied" and 2) a second param. def. is created and tied to the first group. PEST tool complains that you cannot tied parameter to another existing tied param, which is correct! FePEST manages to create the parameters and groups properly at the beginning. But if you edit any parameter, the groups are somehow recreated not fully correct.
Solution: You correct manually the tied parameter(s) (from group 2) by tidying up to another parameter, which is not being "adjustable" / "calibrable" (from group 1).
If you need more details, support team (mike.de@dhigroup.com) is aware of the problematic and has some workarounds.
Apologizes for the inconvenience. We are planning a correction in the next update.
Happy new year!
Carlos Rivera
-
Hi Samia,
Allowing the creation of the material time-stages through the IFM interface is one of the prioritizes for the future release. There are some workaround, but they require few more extra code lines.
Cheers
Carlos
-
Maybe it is worthy for other users: you can work with value = float("nan") and pass this to the API function in order to create the power value. I think a numpy NAN definition should also work.
Cheers
Carlos
-
Hi,
did you figure out a solution to the mentioned problem? Otherwise let us talk in detail through the official support channel (mike@dhigroup.com).
Cheers, Carlos
-
Hi Stephen,
Actually FePEST does not use obs2obs.exe, since we have our own implementation. The easiest workflow is to connect the time series of head measurements to an existing observation point in the FEM file. Later in FePEST, you can create an Observation Definition, which depends on head differences (TIME1 - TIME2). By default the head differences are defined based on consecutive temporal records. HOWEVER, you can manipulate later the table, e.g. in Excel, and edit the time column (e.g. TIME - TIME INITIALS or anything else).
Cheers
Carlos
-
Hi Paul,
The situation explained is a typical case. FEFLOW uses a backward calculation for the budgets. This means that you impose certain Fluid-Flux value and not necesarily you get the same in the budget panels. The budget calculation is based on the primary solution (heads). As you described, the case is very well observable in unsaturated models. From my experience this happens often when you add water into a very unsaturated profile. You can correct this mistmatch by improving the mesh discretization at the location of the boundary and/or using an analytical formulation for the capacity (Unsaturated Settings in the Problem Settings dialog).
Regards
Carlos
-
Hola Javier,
Yes. The search in 2D will give you the node number in the Slice 1. The coordinate display is what you have selected in the menu View -> Coordinate system.
Cheers,
Carlos
-
PS. In Python, the function returns a list with the node number and the distance to the point provided.
-
Hi Javier,
I have double checked the function. It properly returns a node number. I think your problem is the coordinate system. FEFLOW works with the local coordinate system, thus you will need to subtract the origin (X,Y) to the coordinates before you pass these values to the IfmFindNodeAtXY function.
node = IfmFindNodeAtXY(m_pDoc, 352, 1715, pointer1);
IfmInfo(m_pDoc, "Node: %i", node);
The second statement will print the number on the Log panel. After FEFLOW 6.2 (p12), we introduced two more functions for searching nodes or elements:
int (*findElementAtXYZ) (IfmHandle, double x, double y, double z);
int (*findNodeAtXYZ) (IfmHandle, double x, double y, double z, double* dist);
If you need just to know the number of the node and/or element, you can simply create a nodal/elemental expression distribution in FEFLOW GUI. Remember to decrease one unit to the number you get (to be in concordance with C++ counts from zero).
Cheers,
Carlos
-
Dear all,
This bug is already fixed in the new update # 3 of FEFLOW 7.0. The correct link associated is ensured in the MS template.
Best,
Carlos