removing (most) integrals from problem definition files?
Hi all,
I'm thinking about replacing the current syntax:
dw_laplace.i1.Omega( coef.val, s, t )
where 'i1' is
integral_1 = { 'name' : 'i1', 'kind' : 'v', 'quadrature' : 'gauss_o2_d3', }
with simply:
dw_laplace.2.Omega( coef.val, s, t )
Discussion
The only important information in the 'integral' keyword is the integration order - the space dimension is given by the region dimension.
So instead of the integral name, let's use directly the integration order in its place.
The order can be either a positive integer, or 'a' as 'automatic' (for future automatic order determination).
This will simplify most input files, with the only one exception: custom quadratures will still use the current syntax.
What do you think?
r.
Hi Robert,
On Fri, Jun 4, 2010 at 5:50 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Hi all,
I'm thinking about replacing the current syntax:
dw_laplace.i1.Omega( coef.val, s, t )
where 'i1' is
integral_1 = { 'name' : 'i1', 'kind' : 'v', 'quadrature' : 'gauss_o2_d3', }
with simply:
dw_laplace.2.Omega( coef.val, s, t )
Discussion
The only important information in the 'integral' keyword is the integration order - the space dimension is given by the region dimension.
So instead of the integral name, let's use directly the integration order in its place.
The order can be either a positive integer, or 'a' as 'automatic' (for future automatic order determination).
This will simplify most input files, with the only one exception: custom quadratures will still use the current syntax.
What do you think?
+1 I think this is a good idea. If custom quadratures can still use the current syntax, then the existing examples should still work, so no breakage should occur. We would just have to make the restriction that custom integral names should start with a letter (which may already be the case).
Thanks! Logan
On 06/04/10 16:22, Logan Sorenson wrote:
Hi Robert,
On Fri, Jun 4, 2010 at 5:50 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
Hi all,
I'm thinking about replacing the current syntax:
dw_laplace.i1.Omega( coef.val, s, t )
where 'i1' is
integral_1 = { 'name' : 'i1', 'kind' : 'v', 'quadrature' : 'gauss_o2_d3', }
with simply:
dw_laplace.2.Omega( coef.val, s, t )
Discussion
The only important information in the 'integral' keyword is the integration order - the space dimension is given by the region dimension.
So instead of the integral name, let's use directly the integration order in its place.
The order can be either a positive integer, or 'a' as 'automatic' (for future automatic order determination).
This will simplify most input files, with the only one exception: custom quadratures will still use the current syntax.
What do you think?
+1 I think this is a good idea. If custom quadratures can still use the current syntax, then the existing examples should still work, so no breakage should occur. We would just have to make the restriction that custom integral names should start with a letter (which may already be the case).
So far the name is just a string - it can be anything. You are right that after the change it would have to be either an integer, or start with a letter.
Thanks for the feedback!
r.
On 06/08/10 12:18, Robert Cimrman wrote:
On 06/04/10 16:22, Logan Sorenson wrote:
Hi Robert,
On Fri, Jun 4, 2010 at 5:50 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
Hi all,
I'm thinking about replacing the current syntax:
dw_laplace.i1.Omega( coef.val, s, t )
where 'i1' is
integral_1 = { 'name' : 'i1', 'kind' : 'v', 'quadrature' : 'gauss_o2_d3', }
with simply:
dw_laplace.2.Omega( coef.val, s, t )
Discussion
The only important information in the 'integral' keyword is the integration order - the space dimension is given by the region dimension.
So instead of the integral name, let's use directly the integration order in its place.
The order can be either a positive integer, or 'a' as 'automatic' (for future automatic order determination).
This will simplify most input files, with the only one exception: custom quadratures will still use the current syntax.
What do you think?
+1 I think this is a good idea. If custom quadratures can still use the current syntax, then the existing examples should still work, so no breakage should occur. We would just have to make the restriction that custom integral names should start with a letter (which may already be the case).
So far the name is just a string - it can be anything. You are right that after the change it would have to be either an integer, or start with a letter.
Correction: the equation parses does require the integral name to begin with a letter now.
Thanks for the feedback!
r.
It's now at [1], please try!
r. [1] http://github.com/rc/sfepy/tree/master
On 06/08/10 13:38, Robert Cimrman wrote:
On 06/08/10 12:18, Robert Cimrman wrote:
On 06/04/10 16:22, Logan Sorenson wrote:
Hi Robert,
On Fri, Jun 4, 2010 at 5:50 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
Hi all,
I'm thinking about replacing the current syntax:
dw_laplace.i1.Omega( coef.val, s, t )
where 'i1' is
integral_1 = { 'name' : 'i1', 'kind' : 'v', 'quadrature' : 'gauss_o2_d3', }
with simply:
dw_laplace.2.Omega( coef.val, s, t )
Discussion
The only important information in the 'integral' keyword is the integration order - the space dimension is given by the region dimension.
So instead of the integral name, let's use directly the integration order in its place.
The order can be either a positive integer, or 'a' as 'automatic' (for future automatic order determination).
This will simplify most input files, with the only one exception: custom quadratures will still use the current syntax.
What do you think?
+1 I think this is a good idea. If custom quadratures can still use the current syntax, then the existing examples should still work, so no breakage should occur. We would just have to make the restriction that custom integral names should start with a letter (which may already be the case).
So far the name is just a string - it can be anything. You are right that after the change it would have to be either an integer, or start with a letter.
Correction: the equation parses does require the integral name to begin with a letter now.
Thanks for the feedback!
r.
On 06/08/2010 06:35 PM, Robert Cimrman wrote:
It's now at [1], please try!
It works for me, all my tests passed.
vl.
On Tue, Jun 8, 2010 at 2:42 PM, Vladimir Lukes lu...@kme.zcu.cz wrote:
On 06/08/2010 06:35 PM, Robert Cimrman wrote:
It's now at [1], please try!
It works for me, all my tests passed.
vl.
All tests pass here, too.
Logan
On Tue, 2010-06-08 at 16:37 -0400, Logan Sorenson wrote:
I did a git pull in my sfepy directory. After that all tests pass but one known failure. Quantum examples work as expected.
-osman
On 06/09/10 00:25, osman wrote:
On Tue, 2010-06-08 at 16:37 -0400, Logan Sorenson wrote:
I did a git pull in my sfepy directory. After that all tests pass but one known failure. Quantum examples work as expected.
This is a rare state of affairs :)
Thanks to all testers! r.
participants (4)
-
Logan Sorenson -
osman -
Robert Cimrman -
Vladimir Lukes