using field in postproc that was not used in equation solving
I want to define my own field. For example, pressure.
fields = {
'temperature' : ('real', 1, 'Omega', 1),
'pressure' : ('real', 1, 'Omega', 1),
}
variables = {
't' : ('unknown field', 'temperature', 0),
's' : ('test field', 'temperature', 't'),
'p' : ( 'parameter field', 'pressure', {'setter' : 'get_pressure'} ),
}
def get_pressure(ts, coors, region=None):
z = coors[:,2]
return z
functions = {
'get_pressure': (get_pressure,),
}
The idea is to create very primitive field that depends on z coordinates.
Now I want to export the grad(p) to the output mesh. And so I add this in postprocess function:
p_grad = pb.evaluate('ev_grad.i.Omega(p)', mode='el_avg', verbose=False)
out['p'] = Struct(name='output_data', mode='cell', data=p_grad, dofs=None)
But I get the following error:
ValueError: argument p not found!
What I'm doing wrong?
And how can I export the pressure field itself (not its gradient)?
The answer from Robert Cimrman:
Hi,
In a post-processing function, the only variables that are defined are those that are used in the equations. If p is not used, you need to create it, as shown below (also how to save p and its cell averages.
def post_process(out, pb, state, extend=False): from sfepy.base.base import Struct
pvar = pb.create_variables(['p'])['p']
pvar.time_update(None, pb.functions)
out.update(pvar.create_output())
ap = pb.evaluate('ev_volume_integrate.i.Omega(p)', mode='el_avg',p=pvar, verbose=False) out['ap'] = Struct(name='output_data', mode='cell', data=ap, dofs=None)
p_grad = pb.evaluate('ev_grad.i.Omega(p)', mode='el_avg', p=pvar,
verbose=False)
out['gp'] = Struct(name='output_data', mode='cell', data=p_grad,dofs=None)
return outr.
PS: This might be interesting to others, so, if you do not mind, you can forward it to the list.
Just to let you know, Sfepy is now in Nixpkgs.
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/python-modules...
Unfortunately, the build seems to be broken on master. One test fails in "tests/test_splinebox.py" with
Traceback (most recent call last):
File "/nix/store/hzh4nqhzr0a86mh1dd8r806cq5sn95pn-python3.7-numpy-1.18.1/lib/python3.7/site-packages/numpy/core/function_base.py",
line 117, in linspace
num = operator.index(num)
TypeError: 'float' object cannot be interpreted as an integer
If that test is excluded from the build then it builds. I'm assuming that this is an incompatibility between Numpy 1.18.1 and Sfepy 2019.4, which is the current Nixpkgs version of Numpy.
I'm going to repair this by simply omitting that particular test module for now.
-- Daniel Wheeler
Hi Daniel,
that issue was indeed related to NumPy stopping silently casting floating values to ints in the num argument of linspace(), it should be fixed in the current master.
Thank you for your packaging efforts! (The fast/slow test mode [1] is still planned (by switching to pytest), I hope it will be sooner than later.)
Note that meshio is a non-optional run-time dependence now, see [2].
r.
[1] https://github.com/sfepy/sfepy/issues/552 [2] https://github.com/sfepy/sfepy/pull/580
On 2/24/20 11:43 PM, Daniel Wheeler wrote:
Just to let you know, Sfepy is now in Nixpkgs.
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/python-modules...
Unfortunately, the build seems to be broken on master. One test fails in "tests/test_splinebox.py" with
Traceback (most recent call last): File "/nix/store/hzh4nqhzr0a86mh1dd8r806cq5sn95pn-python3.7-numpy-1.18.1/lib/python3.7/site-packages/numpy/core/function_base.py", line 117, in linspace num = operator.index(num) TypeError: 'float' object cannot be interpreted as an integerIf that test is excluded from the build then it builds. I'm assuming that this is an incompatibility between Numpy 1.18.1 and Sfepy 2019.4, which is the current Nixpkgs version of Numpy.
I'm going to repair this by simply omitting that particular test module for now.
On Tue, Feb 25, 2020 at 9:08 AM Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
that issue was indeed related to NumPy stopping silently casting floating values to ints in the num argument of linspace(), it should be fixed in the current master.
I suspected that. Thanks.
Thank you for your packaging efforts! (The fast/slow test mode [1] is still planned (by switching to pytest), I hope it will be sooner than later.)
Great, that will really help.
Note that meshio is a non-optional run-time dependence now, see [2].
Meshio is a very cool package. Long overdue for scientific Python. Is that an option for 2019.4 or on master in future releases?
-- Daniel Wheeler
On 2/25/20 4:25 PM, Daniel Wheeler wrote:
On Tue, Feb 25, 2020 at 9:08 AM Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
that issue was indeed related to NumPy stopping silently casting floating values to ints in the num argument of linspace(), it should be fixed in the current master.
I suspected that. Thanks.
Thank you for your packaging efforts! (The fast/slow test mode [1] is still planned (by switching to pytest), I hope it will be sooner than later.)
Great, that will really help.
Note that meshio is a non-optional run-time dependence now, see [2].
Meshio is a very cool package. Long overdue for scientific Python. Is that an option for 2019.4 or on master in future releases?
The code was merged into master today, and it will be in the next release, together with other significant changes (e.g. Python 3 only from now on).
r.
participants (3)
-
Daniel Wheeler -
FaTune -
Robert Cimrman