FePEST bug: simulated mass concentrations at observation points

I am wondering if other people have encountered this bug as well.
FePEST does not read properly simulated concentrations at observations points. All simulated concentrations > 100 are instead displayed as 100.
Since FePEST uses these "rounded down" concentrations to calculate objective function, it becomes completely useless in my setting.
The issue persists both in 7.3 and 7.4 (downgrading to 7.3 actually fixed another bug).
The observation points appear to work properly in FeFlow itself (i.e. it displays proper concentration values on concentration history charts and in the exported tables)

[size=6pt]Added later[/size]
I have tried to bypass the issue by creating a user-defined parameter (mass concentration / 1000). However, issue persisted (i.e. cutoff threshold got reduced by a factor of 1000). This implies that the FeFlow run by FePEST produces "truncated" concentration field as opposed to one produced by a manual FEM run.

I will documents both bugs and the solution I have used here:
[b]
Bug 1[/b]
FePEST 7.4 does not allow to use tied parameter option. When such parameter is added, FePEST declines to run and displays error message about wrong parameter zone. There is additional sign of this error: when tied parameter is added it does not take default value from the FEM file zone.
[b]Solution[/b]
Downgrade to FeFlow/FePEST 7/3

[b]Bug 2[/b]
FePEST does not extract proper mass concentrations values from the FeFlow model. I.e. simulated concentrations in FePEST are completely different from concentrations in the manual model runs.
[b]Solution[/b]
Bug 2 was found to be linked to the use of a "free surface" option for the top model layer (the rest were set to confined) even though all observation points are well below. Changing model to either confined / phreatic setting fixed the issue (Richard's equation was not tested).
[i]Side note: my original theory was that observations points coordinates are not read properly, so I have experimented with a range of observation points locations (free xyz / slice + xy / node), but neither of these options worked.[/i]

WRT Bug 2: If you set observation points on slices in a free & movable model, they can be moved with the slices, even well below the water table. Use XYZ observation points to avoid this.

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

[quote author=Peter Schätzl link=topic=22092.msg29279#msg29279 date=1609744027]
WRT Bug 2: If you set observation points on slices in a free & movable model, they can be moved with the slices, even well below the water table. Use XYZ observation points to avoid this.
[/quote]
I was using free xyz for my observation points when bug manifested itself (though, I did check other options as well when looking for the solution).
Moreover, all my slices below the top one were set to confined setting so they don't move. Additionally I have set up elevations so that none of the lower slices need to move.