I see some probing functions in the code although no examples or documentation. Is this still under development? I'm looking for a way to extract info from the results file.
On 04/04/10 18:47, freevryheid wrote:
I see some probing functions in the code although no examples or documentation. Is this still under development? I'm looking for a way to extract info from the results file.
Probing works ok, it's just a matter of non-documentation... I will try to make an example during today.
r.
On 04/06/10 09:46, Robert Cimrman wrote:
On 04/04/10 18:47, freevryheid wrote:
I see some probing functions in the code although no examples or documentation. Is this still under development? I'm looking for a way to extract info from the results file.
Probing works ok, it's just a matter of non-documentation... I will try to make an example during today.
It's in the git repo, see examples/linear_elasticity/linear_elastic_probes.py file. The example demonstrates both the post_process_hook and probe_hook options.
Now we should think how to include this information into the docs.
r.
Thanks Robert!
On Tue, Apr 6, 2010 at 7:11 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On 04/06/10 09:46, Robert Cimrman wrote:
On 04/04/10 18:47, freevryheid wrote:
I see some probing functions in the code although no examples or documentation. Is this still under development? I'm looking for a way to extract info from the results file.
Probing works ok, it's just a matter of non-documentation... I will try to make an example during today.
It's in the git repo, see examples/linear_elasticity/linear_elastic_probes.py file. The example demonstrates both the post_process_hook and probe_hook options.
Now we should think how to include this information into the docs.
r.
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
On 04/06/10 16:44, Andre Smit wrote:
Thanks Robert!
Hth! Let me know how it goes...
r.
On Tue, Apr 6, 2010 at 7:11 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
On 04/06/10 09:46, Robert Cimrman wrote:
On 04/04/10 18:47, freevryheid wrote:
I see some probing functions in the code although no examples or documentation. Is this still under development? I'm looking for a way to extract info from the results file.
Probing works ok, it's just a matter of non-documentation... I will try to make an example during today.
It's in the git repo, see examples/linear_elasticity/linear_elastic_probes.py file. The example demonstrates both the post_process_hook and probe_hook options.
Now we should think how to include this information into the docs.
r.
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
Hey guys
I adapted the _probes code to analyze my 2D model with triangle elements (see attached).
I ran into the following error:
File "/home/grassy/sfepy/sfepy/fem/fea.py", line 394, in describe_geometry qcs=collect_quadratures()[quad_name]) KeyError: 'gauss_o1_d2'
so I added the following class to quadratures.py in the source (based on Table 6.3.1 in attached fea6.pdf): ## # 04.04.2010 class GaussO1G23( Quadrature ): family = 'gauss_o1_d2' name = 'gauss_s_o1_g2_3'
def __init__( self ):
c = 1.0 / 3.0
w = 1.0
self.vals = nm.array( [[c, c]], dtype = nm.float64 )
self.weights = nm.array( [w], dtype = nm.float64 )
The problem computes but the output is incorrect. Any suggestions
On 04/07/10 20:27, Andre Smit wrote:
Hey guys
I adapted the _probes code to analyze my 2D model with triangle elements (see attached).
I ran into the following error:
File "/home/grassy/sfepy/sfepy/fem/fea.py", line 394, in describe_geometry qcs=collect_quadratures()[quad_name]) KeyError: 'gauss_o1_d2'
Warning first: you have found your first skeleton in the cupboard... The quadratures are very incomplete, and I guess some have not the order they claim. If you could review them using e.g. the tables in fea6.pdf, it would be great.
The state is as it is, as I am in process of refactoring sfepy/fem, during which that stuff is going to change completely - unfortunately it progresses more slowly then I originally expected.
so I added the following class to quadratures.py in the source (based on Table 6.3.1 in attached fea6.pdf): ## # 04.04.2010 class GaussO1G23( Quadrature ): family = 'gauss_o1_d2' name = 'gauss_s_o1_g2_3'
def __init__( self ): c = 1.0 / 3.0 w = 1.0 self.vals = nm.array( [[c, c]], dtype = nm.float64 ) self.weights = nm.array( [w], dtype = nm.float64 )
The problem computes but the output is incorrect. Any suggestions
I cannot run your example - there seems to be some problem with the mesh. I guess it's because there are also point and line cells.
Note that in sfepy, the quadrature are defined in [0, 1], so the area of triangle is 0.5. Hence w = 0.5. (Integral of 1 over the triangle should be its area - this should be added to unit tests).
r.
I cannot run your example - there seems to be some problem with the mesh. I
guess it's because there are also point and line cells.
I'm using gmsh for the modeling - yes, I see it includes point and line cells (never noticed before). That may be the problem - let me explore. BTW, what app(s) do you use for meshing?
On 04/09/10 14:45, Andre Smit wrote:
I cannot run your example - there seems to be some problem with the mesh. I
guess it's because there are also point and line cells.
I'm using gmsh for the modeling - yes, I see it includes point and line cells (never noticed before). That may be the problem - let me explore. BTW, what app(s) do you use for meshing?
Apart from commercial apps (I often bother colelagues at work) I use also gmsh
- the 'mesh' format (a matter of habit), or sometimes tetgen.
r.
I've "fixed" the mesh as saved in mesh format as attached - the problem output didn't change though.
On 04/09/10 16:06, Andre Smit wrote:
I've "fixed" the mesh as saved in mesh format as attached - the problem output didn't change though.
This is what I got... So it runs now. I had to dump the result to VTK before viewing though, there is some problem with GenericFileSource in 2D.
Do you get the same values?
r.
Robert - yes, this is what I get too, were you able to generate the probe plots using the source in this thread - I get these:
Andre
Note that I am probing along the x and y symmetrical axes on which boundary conditions are set.
On Fri, Apr 9, 2010 at 9:29 AM, Andre Smit freev...@gmail.com wrote:
Robert - yes, this is what I get too, were you able to generate the probe plots using the source in this thread - I get these:
Andre
On 04/09/10 16:32, Andre Smit wrote:
Note that I am probing along the x and y symmetrical axes on which boundary conditions are set.
The results are already computed, so it does not matter, if the boundary values are computed or set by BC.
r.
On Fri, Apr 9, 2010 at 9:29 AM, Andre Smitfreev...@gmail.com wrote:
Robert - yes, this is what I get too, were you able to generate the probe plots using the source in this thread - I get these:
Andre
On 04/09/10 16:29, Andre Smit wrote:
Robert - yes, this is what I get too, were you able to generate the probe plots using the source in this thread - I get these:
Ah, ok, I just sent an e-mail asking this. It seems to me, that, as you are going over the boundary, sometimes the point goes off due to round-off errors. what if you move the probe lines slightly into the domain?
r.
On 04/09/10 16:35, Robert Cimrman wrote:
On 04/09/10 16:29, Andre Smit wrote:
Robert - yes, this is what I get too, were you able to generate the probe plots using the source in this thread - I get these:
Ah, ok, I just sent an e-mail asking this. It seems to me, that, as you are going over the boundary, sometimes the point goes off due to round-off errors. what if you move the probe lines slightly into the domain?
Trying this caused a segfault. There is something very fishy in 2D probing. I tried it always in 3D...
r.
Yep - same here:
probe: 0 line [[ 1. 1.], [ 74. 74.]] probe: interpolating from 57 nodes to 10 nodes... probe: interpolator: 0.000000 s probe: ...done probe: interpolating from 57 nodes to 11 nodes... probe: interpolator: 0.000000 s probe: ...done probe: interpolating from 57 nodes to 11 nodes... probe: interpolator: 0.000000 s probe: ...done probe: interpolating from 57 nodes to 11 nodes... Segmentation fault (core dumped)
On Fri, Apr 9, 2010 at 9:48 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On 04/09/10 16:35, Robert Cimrman wrote:
On 04/09/10 16:29, Andre Smit wrote:
Robert - yes, this is what I get too, were you able to generate the probe plots using the source in this thread - I get these:
Ah, ok, I just sent an e-mail asking this. It seems to me, that, as you are going over the boundary, sometimes the point goes off due to round-off errors. what if you move the probe lines slightly into the domain?
Trying this caused a segfault. There is something very fishy in 2D probing. I tried it always in 3D...
r.
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
I think I found the culprit - it's related to the P0 approximation used to interpolate the cell data. I will have to think about how to fix it.
r.
On 04/09/10 16:52, Andre Smit wrote:
Yep - same here:
probe: 0 line [[ 1. 1.], [ 74. 74.]] probe: interpolating from 57 nodes to 10 nodes... probe: interpolator: 0.000000 s probe: ...done probe: interpolating from 57 nodes to 11 nodes... probe: interpolator: 0.000000 s probe: ...done probe: interpolating from 57 nodes to 11 nodes... probe: interpolator: 0.000000 s probe: ...done probe: interpolating from 57 nodes to 11 nodes... Segmentation fault (core dumped)
On Fri, Apr 9, 2010 at 9:48 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
On 04/09/10 16:35, Robert Cimrman wrote:
On 04/09/10 16:29, Andre Smit wrote:
Robert - yes, this is what I get too, were you able to generate the probe plots using the source in this thread - I get these:
Ah, ok, I just sent an e-mail asking this. It seems to me, that, as you are going over the boundary, sometimes the point goes off due to round-off errors. what if you move the probe lines slightly into the domain?
Trying this caused a segfault. There is something very fishy in 2D probing. I tried it always in 3D...
r.
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
This seems to work:
'sym_tensor' : ((3,1), 'real', 'Omega', {'Omega' : '2_3_P1'}),
Could it be that since the triangle only has
On Fri, Apr 9, 2010 at 10:17 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
I think I found the culprit - it's related to the P0 approximation used to interpolate the cell data. I will have to think about how to fix it.
r.
On 04/09/10 16:52, Andre Smit wrote:
Yep - same here:
probe: 0 line [[ 1. 1.], [ 74. 74.]] probe: interpolating from 57 nodes to 10 nodes... probe: interpolator: 0.000000 s probe: ...done probe: interpolating from 57 nodes to 11 nodes... probe: interpolator: 0.000000 s probe: ...done probe: interpolating from 57 nodes to 11 nodes... probe: interpolator: 0.000000 s probe: ...done probe: interpolating from 57 nodes to 11 nodes... Segmentation fault (core dumped)
On Fri, Apr 9, 2010 at 9:48 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
On 04/09/10 16:35, Robert Cimrman wrote:
On 04/09/10 16:29, Andre Smit wrote:
Robert - yes, this is what I get too, were you able to generate the
probe plots using the source in this thread - I get these:
Ah, ok, I just sent an e-mail asking this. It seems to me, that, as you are going over the boundary, sometimes the point goes off due to round-off errors. what if you move the probe lines slightly into the domain?
Trying this caused a segfault. There is something very fishy in 2D probing. I tried it always in 3D...
r.
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel...@googlegroups.comsfepy-devel%...@googlegroups.com
sfepy-devel%2...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel...@googlegroups.comsfepy-devel%...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
On 04/09/10 17:28, Andre Smit wrote:
This seems to work:
'sym_tensor' : ((3,1), 'real', 'Omega', {'Omega' : '2_3_P1'}),
Could it be that since the triangle only has
Yes, I will have to use P1 and Q1 for the geometry even if the data are P0 and Q0, otherwise it is not possible to locate correctly the element a point is in.
You can use this workaround for the moment.
On Fri, Apr 9, 2010 at 10:17 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
I think I found the culprit - it's related to the P0 approximation used to interpolate the cell data. I will have to think about how to fix it.
Thanks for spotting the bug!
r.
On 04/09/10 17:31, Robert Cimrman wrote:
On 04/09/10 17:28, Andre Smit wrote:
This seems to work:
'sym_tensor' : ((3,1), 'real', 'Omega', {'Omega' : '2_3_P1'}),
Could it be that since the triangle only has
Yes, I will have to use P1 and Q1 for the geometry even if the data are P0 and Q0, otherwise it is not possible to locate correctly the element a point is in.
You can use this workaround for the moment.
Actually not - I guess it gives incorrect results - the data are really P0, and it does not segfault, because in the mesh there is more cells than vertices. It should be fixed by tomorrow.
r.
On 04/09/10 17:49, Robert Cimrman wrote:
On 04/09/10 17:31, Robert Cimrman wrote:
On 04/09/10 17:28, Andre Smit wrote:
This seems to work:
'sym_tensor' : ((3,1), 'real', 'Omega', {'Omega' : '2_3_P1'}),
Could it be that since the triangle only has
Yes, I will have to use P1 and Q1 for the geometry even if the data are P0 and Q0, otherwise it is not possible to locate correctly the element a point is in.
You can use this workaround for the moment.
Actually not - I guess it gives incorrect results - the data are really P0, and it does not segfault, because in the mesh there is more cells than vertices. It should be fixed by tomorrow.
It should be fixed at [1] now. Test it, please, and report any problems.
r.
It works. I still had to move the probe lines away from the symmetry axes to avoid the "nans" in the output. To investigate further I modeled the complete disk and not just the quarter. This model has many more elements. probes.py failed with the following error:
grassy@lapdog:~/sfepy_dev/sfepy$ ./probe.py ./pyfem/its2D_probes.py ./pyfem/output/its2Dc.h5 probe: left over: ['_filename', '__builtins__', '__file__', '__name__', '__package__', 'youngpoisson_to_lame', 'filename', 'stress_strain', 'probe_hook', 'stiffness_tensor_youngpoisson', 'gen_lines', 'np', 'get_pars', '__doc__'] probe: results in: ./pyfem/output/its2Dc.h5 probe: loaded: ['cauchy_stress', 'cauchy_strain', 'u'] probe: reading mesh (pyfem/its2Dc.mesh)... probe: ...done in 0.18 s probe: setting up domain edges... probe: ...done in 0.21 s probe: creating regions... probe: Top probe: Omega probe: Bottom probe: ...done in 0.06 s probe: iconn: 0.000000 s probe: ctree: 0.000000 s probe: iconn: 0.000000 s probe: ctree: 0.000000 s probe: 0 line [[ 0. 0.], [ 75. 0.]] probe: interpolating from 2385 nodes to 10 nodes... probe: interpolator: 0.000000 s probe: ...done Traceback (most recent call last): File "./probe.py", line 293, in <module> main() File "./probe.py", line 290, in main generate_probes(filename_input, filename_results, options) File "./probe.py", line 117, in generate_probes out = probe_hook(data, probe, labels[ip], problem) File "./pyfem/its2D_probes.py", line 75, in probe_hook results['u'] = get_it('u', 'u') File "./pyfem/its2D_probes.py", line 70, in get_it pars, vals = probe(var) File "/home/grassy/sfepy_dev/sfepy/sfepy/fem/probes.py", line 109, in __call__ return self.probe(variable) File "/home/grassy/sfepy_dev/sfepy/sfepy/fem/probes.py", line 134, in probe refine_flag = self.refine_points(variable, points, cells) File "/home/grassy/sfepy_dev/sfepy/sfepy/fem/probes.py", line 157, in refine_points ed = variable.get_element_diameters(cells, 0) File "/home/grassy/sfepy_dev/sfepy/sfepy/fem/variables.py", line 1880, in get_element_diameters ap = field.aps.aps_per_group[ig] KeyError: 110609
The input file and mesh are attached.
On 04/11/10 03:31, Andre Smit wrote:
It works. I still had to move the probe lines away from the symmetry axes to avoid the "nans" in the output. To investigate further I modeled the complete disk and not just the quarter. This model has many more elements. probes.py failed with the following error:
grassy@lapdog:~/sfepy_dev/sfepy$ ./probe.py ./pyfem/its2D_probes.py ./pyfem/output/its2Dc.h5 probe: left over: ['_filename', '__builtins__', '__file__', '__name__', '__package__', 'youngpoisson_to_lame', 'filename', 'stress_strain', 'probe_hook', 'stiffness_tensor_youngpoisson', 'gen_lines', 'np', 'get_pars', '__doc__'] probe: results in: ./pyfem/output/its2Dc.h5 probe: loaded: ['cauchy_stress', 'cauchy_strain', 'u'] probe: reading mesh (pyfem/its2Dc.mesh)... probe: ...done in 0.18 s probe: setting up domain edges... probe: ...done in 0.21 s probe: creating regions... probe: Top probe: Omega probe: Bottom probe: ...done in 0.06 s probe: iconn: 0.000000 s probe: ctree: 0.000000 s probe: iconn: 0.000000 s probe: ctree: 0.000000 s probe: 0 line [[ 0. 0.], [ 75. 0.]] probe: interpolating from 2385 nodes to 10 nodes... probe: interpolator: 0.000000 s probe: ...done Traceback (most recent call last): File "./probe.py", line 293, in<module> main() File "./probe.py", line 290, in main generate_probes(filename_input, filename_results, options) File "./probe.py", line 117, in generate_probes out = probe_hook(data, probe, labels[ip], problem) File "./pyfem/its2D_probes.py", line 75, in probe_hook results['u'] = get_it('u', 'u') File "./pyfem/its2D_probes.py", line 70, in get_it pars, vals = probe(var) File "/home/grassy/sfepy_dev/sfepy/sfepy/fem/probes.py", line 109, in __call__ return self.probe(variable) File "/home/grassy/sfepy_dev/sfepy/sfepy/fem/probes.py", line 134, in probe refine_flag = self.refine_points(variable, points, cells) File "/home/grassy/sfepy_dev/sfepy/sfepy/fem/probes.py", line 157, in refine_points ed = variable.get_element_diameters(cells, 0) File "/home/grassy/sfepy_dev/sfepy/sfepy/fem/variables.py", line 1880, in get_element_diameters ap = field.aps.aps_per_group[ig] KeyError: 110609
The input file and mesh are attached.
Good catch! It is caused by the fact, that the first node is not in any element... I have fixed that, but still there are nans. I am looking at the problem now.
r.
On 04/12/10 08:59, Robert Cimrman wrote:
On 04/11/10 03:31, Andre Smit wrote:
It works. I still had to move the probe lines away from the symmetry axes to avoid the "nans" in the output. To investigate further I modeled the complete disk and not just the quarter. This model has many more elements. probes.py failed with the following error:
grassy@lapdog:~/sfepy_dev/sfepy$ ./probe.py ./pyfem/its2D_probes.py ./pyfem/output/its2Dc.h5 probe: left over: ['_filename', '__builtins__', '__file__', '__name__', '__package__', 'youngpoisson_to_lame', 'filename', 'stress_strain', 'probe_hook', 'stiffness_tensor_youngpoisson', 'gen_lines', 'np', 'get_pars', '__doc__'] probe: results in: ./pyfem/output/its2Dc.h5 probe: loaded: ['cauchy_stress', 'cauchy_strain', 'u'] probe: reading mesh (pyfem/its2Dc.mesh)... probe: ...done in 0.18 s probe: setting up domain edges... probe: ...done in 0.21 s probe: creating regions... probe: Top probe: Omega probe: Bottom probe: ...done in 0.06 s probe: iconn: 0.000000 s probe: ctree: 0.000000 s probe: iconn: 0.000000 s probe: ctree: 0.000000 s probe: 0 line [[ 0. 0.], [ 75. 0.]] probe: interpolating from 2385 nodes to 10 nodes... probe: interpolator: 0.000000 s probe: ...done Traceback (most recent call last): File "./probe.py", line 293, in<module> main() File "./probe.py", line 290, in main generate_probes(filename_input, filename_results, options) File "./probe.py", line 117, in generate_probes out = probe_hook(data, probe, labels[ip], problem) File "./pyfem/its2D_probes.py", line 75, in probe_hook results['u'] = get_it('u', 'u') File "./pyfem/its2D_probes.py", line 70, in get_it pars, vals = probe(var) File "/home/grassy/sfepy_dev/sfepy/sfepy/fem/probes.py", line 109, in __call__ return self.probe(variable) File "/home/grassy/sfepy_dev/sfepy/sfepy/fem/probes.py", line 134, in probe refine_flag = self.refine_points(variable, points, cells) File "/home/grassy/sfepy_dev/sfepy/sfepy/fem/probes.py", line 157, in refine_points ed = variable.get_element_diameters(cells, 0) File "/home/grassy/sfepy_dev/sfepy/sfepy/fem/variables.py", line 1880, in get_element_diameters ap = field.aps.aps_per_group[ig] KeyError: 110609
The input file and mesh are attached.
Good catch! It is caused by the fact, that the first node is not in any element... I have fixed that, but still there are nans. I am looking at the problem now.
OK, now it should (finally) work. I have fixed several things related to 2D, and simplex elements. I have also fixed postproc.py for 2D results in hdf5 format, so './postproc.py its2Dc.h5 -b' works.
Thanks for the reports, they are very valuable, and help improving the code!
r.
Nice - I've attached results of analyses of the 2D point loaded disk using sfepy compared to output using Student's Quickfield.
d = displacement, s = stress, e = strain x = on line along x-axis y = on line along y-axis
The plots compare favorably except perhaps the displacements.
On 04/12/10 16:03, Andre Smit wrote:
Nice - I've attached results of analyses of the 2D point loaded disk using sfepy compared to output using Student's Quickfield.
d = displacement, s = stress, e = strain x = on line along x-axis y = on line along y-axis
The plots compare favorably except perhaps the displacements.
I do not like the displacement plots - they do not agree with what I can see when I plot the 3D results with Mayavi... The Mayavi plots are much more like the Student's Quickfield results.
So there might be another problem. But we have got a bit further :)
r.
On 04/12/10 16:19, Robert Cimrman wrote:
On 04/12/10 16:03, Andre Smit wrote:
Nice - I've attached results of analyses of the 2D point loaded disk using sfepy compared to output using Student's Quickfield.
d = displacement, s = stress, e = strain x = on line along x-axis y = on line along y-axis
The plots compare favorably except perhaps the displacements.
I do not like the displacement plots - they do not agree with what I can see when I plot the 3D results with Mayavi... The Mayavi plots are much more like the Student's Quickfield results.
So there might be another problem. But we have got a bit further :)
It seems to me, that the problem is related to that fact that the vertex 0 is not in any element. This shifts all the indices by one, and the displacement probe returns gibberish. Stresses and strains are ok, as they are element-based. Would you mind trying it with a mesh without such "unused" nodes?
r.
On 04/12/10 17:54, Robert Cimrman wrote:
On 04/12/10 16:19, Robert Cimrman wrote:
On 04/12/10 16:03, Andre Smit wrote:
Nice - I've attached results of analyses of the 2D point loaded disk using sfepy compared to output using Student's Quickfield.
d = displacement, s = stress, e = strain x = on line along x-axis y = on line along y-axis
The plots compare favorably except perhaps the displacements.
I do not like the displacement plots - they do not agree with what I can see when I plot the 3D results with Mayavi... The Mayavi plots are much more like the Student's Quickfield results.
So there might be another problem. But we have got a bit further :)
It seems to me, that the problem is related to that fact that the vertex 0 is not in any element. This shifts all the indices by one, and the displacement probe returns gibberish. Stresses and strains are ok, as they are element-based. Would you mind trying it with a mesh without such "unused" nodes?
It is really the cause - look at the attached figures. I have added a triangle
1 2257 2260 6
at the end of the list of triangles in the mesh file - this is wrong (and causes the artifact near zero in the plots), but it served its purpose - to demonstrate the effect.
I will "fix" sfepy to warn that probing results will be wrong in case of such nodes - fixing it properly would be rather difficult, and is not worth doing IMHO.
We can add a script to sfepy for fixing meshes in this respect... If you think it's worth doing, submit a new issue, please. (A good issue for newbies willing to get their hands dirty, btw.)
cheers, r.
OK - One needs to define physical groups in gmsh to avoid the problem as outlined above. More info here:
http://www.geuz.org/pipermail/gmsh/2010/005349.html
I like the idea of having some simple meshing scripts for sfepy though.
On 04/09/10 16:21, Robert Cimrman wrote:
On 04/09/10 16:06, Andre Smit wrote:
I've "fixed" the mesh as saved in mesh format as attached - the problem output didn't change though.
This is what I got... So it runs now. I had to dump the result to VTK before viewing though, there is some problem with GenericFileSource in 2D.
Do you get the same values?
When running (after adding the GaussO1G23 class with w = 0.5)
./probe.py work/andre/its2D_probes.py its2D.h5
I get some figures, but there are nan values - is that what you meant with "wrong"?
r.
participants (3)
-
Andre Smit
-
freevryheid
-
Robert Cimrman