[fem-fenics] ufl.m

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[fem-fenics] ufl.m

Eugenio Gianniti
Dear Marco, and all,

I attach the ufl.m function I have previously mentioned for review. I still have to edit something, namely on line 45 a check for the .ufl file extension is performed with a case insensitive matching, but I should ensure with a couple more instructions that the lower case version is used, as in the functions that compile the .oct files for the problem at hand.

There is also an issue due to a bug present in the stable version currently distributed, but solved in the development version. I also attach script.m, containing basically the Poisson.ufl of the homonymous example, but with ufl in first position. I noticed that my function works as I expect with the simpler lines, but Octave errors out when trying to execute the second and the ninth (I added comments to highlight those lines). This happens only in the stable release, on the other hand the development version goes on without complaining. Here is the error:

>> script
parse error near line 2 of file /Users/eugenio/tests/script.m

  syntax error

>>> ufl element = FiniteElement("Lagrange", triangle, 1)

How should I proceed with respect to this behaviour?

Eugenio


ufl.m (2K) Download Attachment
script.m (396 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] ufl.m

c.-2

On 21 May 2014, at 14:58, Eugenio Gianniti <[hidden email]> wrote:

> Dear Marco, and all,
>
> I attach the ufl.m function I have previously mentioned for review. I still have to edit something, namely on line 45 a check for the .ufl file extension is performed with a case insensitive matching, but I should ensure with a couple more instructions that the lower case version is used, as in the functions that compile the .oct files for the problem at hand.
>
> There is also an issue due to a bug present in the stable version currently distributed, but solved in the development version. I also attach script.m, containing basically the Poisson.ufl of the homonymous example, but with ufl in first position. I noticed that my function works as I expect with the simpler lines, but Octave errors out when trying to execute the second and the ninth (I added comments to highlight those lines). This happens only in the stable release, on the other hand the development version goes on without complaining. Here is the error:
>
>>> script
> parse error near line 2 of file /Users/eugenio/tests/script.m
>
>  syntax error
>
>>>> ufl element = FiniteElement("Lagrange", triangle, 1)
>
> How should I proceed with respect to this behaviour?
>
> Eugenio
>

Eugenio,

Please share you code in the form of changesets
through the patch tracker, rather than sending them
to the list.

c.


Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] ufl.m

Eugenio Gianniti

On 21 May 2014, at 15:20, c. <[hidden email]> wrote:


On 21 May 2014, at 14:58, Eugenio Gianniti <[hidden email]> wrote:

Dear Marco, and all,

I attach the ufl.m function I have previously mentioned for review. I still have to edit something, namely on line 45 a check for the .ufl file extension is performed with a case insensitive matching, but I should ensure with a couple more instructions that the lower case version is used, as in the functions that compile the .oct files for the problem at hand.

There is also an issue due to a bug present in the stable version currently distributed, but solved in the development version. I also attach script.m, containing basically the Poisson.ufl of the homonymous example, but with ufl in first position. I noticed that my function works as I expect with the simpler lines, but Octave errors out when trying to execute the second and the ninth (I added comments to highlight those lines). This happens only in the stable release, on the other hand the development version goes on without complaining. Here is the error:

script
parse error near line 2 of file /Users/eugenio/tests/script.m

syntax error

ufl element = FiniteElement("Lagrange", triangle, 1)

How should I proceed with respect to this behaviour?

Eugenio


Eugenio,

Please share you code in the form of changesets
through the patch tracker, rather than sending them 
to the list.

c.

Ok, here is the link to the changeset on the patch tracker:

Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] ufl.m

Marco Vassallo
In reply to this post by Eugenio Gianniti



On Wed, May 21, 2014 at 2:58 PM, Eugenio Gianniti <[hidden email]> wrote:
Dear Marco, and all,

I attach the ufl.m function I have previously mentioned for review.

Thanks, really good job.
 
I still have to edit something, namely on line 45 a check for the .ufl file extension is performed with a case insensitive matching, but I should ensure with a couple more instructions that the lower case version is used, as in the functions that compile the .oct files for the problem at hand.

You should also check that we are not overwriting an existing file.
 
There is also an issue due to a bug present in the stable version currently distributed, but solved in the development version. I also attach script.m, containing basically the Poisson.ufl of the homonymous example, but with ufl in first position. I noticed that my function works as I expect with the simpler lines, but Octave errors out when trying to execute the second and the ninth (I added comments to highlight those lines). This happens only in the stable release, on the other hand the development version goes on without complaining. Here is the error:

>> script
parse error near line 2 of file /Users/eugenio/tests/script.m

  syntax error

>>> ufl element = FiniteElement("Lagrange", triangle, 1)

How should I proceed with respect to this behaviour?

I don't have the stable version so I don't know how to reproduce it.
However it could be the "," as it is present only in this two lines.
But, as it has been fixed in the development version, probably someone here in the list can explain this behavior. 

Marco
Eugenio


Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] ufl.m

Eugenio Gianniti

On 21 May 2014, at 15:53, Marco Vassallo <[hidden email]> wrote:




On Wed, May 21, 2014 at 2:58 PM, Eugenio Gianniti <[hidden email]> wrote:
Dear Marco, and all,

I attach the ufl.m function I have previously mentioned for review.

Thanks, really good job.
 
I still have to edit something, namely on line 45 a check for the .ufl file extension is performed with a case insensitive matching, but I should ensure with a couple more instructions that the lower case version is used, as in the functions that compile the .oct files for the problem at hand.

You should also check that we are not overwriting an existing file.

In this case it should error out complaining about the existing file and leaving it as it is, I would say. It is probably useful to add another command to delete a file and start from scratch, something like:
          >> ufl clear filename
or
          >> ufl rm filename
Do you agree?

 
There is also an issue due to a bug present in the stable version currently distributed, but solved in the development version. I also attach script.m, containing basically the Poisson.ufl of the homonymous example, but with ufl in first position. I noticed that my function works as I expect with the simpler lines, but Octave errors out when trying to execute the second and the ninth (I added comments to highlight those lines). This happens only in the stable release, on the other hand the development version goes on without complaining. Here is the error:

>> script
parse error near line 2 of file /Users/eugenio/tests/script.m

  syntax error

>>> ufl element = FiniteElement("Lagrange", triangle, 1)

How should I proceed with respect to this behaviour?

I don't have the stable version so I don't know how to reproduce it.
However it could be the "," as it is present only in this two lines.
But, as it has been fixed in the development version, probably someone here in the list can explain this behaviour. 

I am not really worried by this bug per se, in any case it has been solved in the development code, but my doubts are mainly:
      1) Should I look for the relevant bug report in the bug tracker and point out that this needs to be fixed also in the stable release? Or maybe just ask when it is scheduled to be included in it?
      2) Should I create a new branch to hold changesets related to this functionality, so that it does not make its way to the released package until the stable release of Octave allows it to work properly? I do not know what is the calendar you have in mind for fem-fenics releases, nor the main Octave’s, but it could be useful should the necessity arise.

Eugenio


Marco
Eugenio

Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] ufl.m

Marco Vassallo



On Wed, May 21, 2014 at 4:33 PM, Eugenio Gianniti <[hidden email]> wrote:

On 21 May 2014, at 15:53, Marco Vassallo <[hidden email]> wrote:




On Wed, May 21, 2014 at 2:58 PM, Eugenio Gianniti <[hidden email]> wrote:
Dear Marco, and all,

I attach the ufl.m function I have previously mentioned for review.

Thanks, really good job.
 
I still have to edit something, namely on line 45 a check for the .ufl file extension is performed with a case insensitive matching, but I should ensure with a couple more instructions that the lower case version is used, as in the functions that compile the .oct files for the problem at hand.

You should also check that we are not overwriting an existing file.

In this case it should error out complaining about the existing file and leaving it as it is, I would say. It is probably useful to add another command to delete a file and start from scratch, something like:
          >> ufl clear filename
or
          >> ufl rm filename
Do you agree?

 
There is also an issue due to a bug present in the stable version currently distributed, but solved in the development version. I also attach script.m, containing basically the Poisson.ufl of the homonymous example, but with ufl in first position. I noticed that my function works as I expect with the simpler lines, but Octave errors out when trying to execute the second and the ninth (I added comments to highlight those lines). This happens only in the stable release, on the other hand the development version goes on without complaining. Here is the error:

>> script
parse error near line 2 of file /Users/eugenio/tests/script.m

  syntax error

>>> ufl element = FiniteElement("Lagrange", triangle, 1)

How should I proceed with respect to this behaviour?

I don't have the stable version so I don't know how to reproduce it.
However it could be the "," as it is present only in this two lines.
But, as it has been fixed in the development version, probably someone here in the list can explain this behaviour. 

I am not really worried by this bug per se, in any case it has been solved in the development code, but my doubts are mainly:
      1) Should I look for the relevant bug report in the bug tracker and point out that this needs to be fixed also in the stable release? Or maybe just ask when it is scheduled to be included in it?
      2) Should I create a new branch to hold changesets related to this functionality, so that it does not make its way to the released package until the stable release of Octave allows it to work properly? I do not know what is the calendar you have in mind for fem-fenics releases, nor the main Octave’s, but it could be useful should the necessity arise.


Don't worry too much about it. We still have the import_ufl_Problem function which works on the stable function.
I was wondering if we should compile the code once the "end" command has been given, just to be sure that the code is correct and printing out the ffc error if it is not the case.
What do you think about it?
 
Eugenio


Marco
Eugenio


Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] ufl.m

Eugenio Gianniti

On 21 May 2014, at 17:00, Marco Vassallo <[hidden email]> wrote:




On Wed, May 21, 2014 at 4:33 PM, Eugenio Gianniti <[hidden email]> wrote:

On 21 May 2014, at 15:53, Marco Vassallo <[hidden email]> wrote:




On Wed, May 21, 2014 at 2:58 PM, Eugenio Gianniti <[hidden email]> wrote:
Dear Marco, and all,

I attach the ufl.m function I have previously mentioned for review.

Thanks, really good job.
 
I still have to edit something, namely on line 45 a check for the .ufl file extension is performed with a case insensitive matching, but I should ensure with a couple more instructions that the lower case version is used, as in the functions that compile the .oct files for the problem at hand.

You should also check that we are not overwriting an existing file.

In this case it should error out complaining about the existing file and leaving it as it is, I would say. It is probably useful to add another command to delete a file and start from scratch, something like:
          >> ufl clear filename
or
          >> ufl rm filename
Do you agree?

 
There is also an issue due to a bug present in the stable version currently distributed, but solved in the development version. I also attach script.m, containing basically the Poisson.ufl of the homonymous example, but with ufl in first position. I noticed that my function works as I expect with the simpler lines, but Octave errors out when trying to execute the second and the ninth (I added comments to highlight those lines). This happens only in the stable release, on the other hand the development version goes on without complaining. Here is the error:

>> script
parse error near line 2 of file /Users/eugenio/tests/script.m

  syntax error

>>> ufl element = FiniteElement("Lagrange", triangle, 1)

How should I proceed with respect to this behaviour?

I don't have the stable version so I don't know how to reproduce it.
However it could be the "," as it is present only in this two lines.
But, as it has been fixed in the development version, probably someone here in the list can explain this behaviour. 

I am not really worried by this bug per se, in any case it has been solved in the development code, but my doubts are mainly:
      1) Should I look for the relevant bug report in the bug tracker and point out that this needs to be fixed also in the stable release? Or maybe just ask when it is scheduled to be included in it?
      2) Should I create a new branch to hold changesets related to this functionality, so that it does not make its way to the released package until the stable release of Octave allows it to work properly? I do not know what is the calendar you have in mind for fem-fenics releases, nor the main Octave’s, but it could be useful should the necessity arise.


Don't worry too much about it. We still have the import_ufl_Problem function which works on the stable function.
I was wondering if we should compile the code once the "end" command has been given, just to be sure that the code is correct and printing out the ffc error if it is not the case.
What do you think about it?

It can be a nice feature. I would also check for an argument given to the “ufl end” instruction to allow the choice of what is in the ufl snippet. I mean, I would let the user decide which one of the import_ufl_*.m s/he wants to use for that particular file.

 
Eugenio


Marco
Eugenio



Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] ufl.m

Eugenio Gianniti

On 21 May 2014, at 17:29, Eugenio Gianniti <[hidden email]> wrote:


On 21 May 2014, at 17:00, Marco Vassallo <[hidden email]> wrote:




On Wed, May 21, 2014 at 4:33 PM, Eugenio Gianniti <[hidden email]> wrote:

On 21 May 2014, at 15:53, Marco Vassallo <[hidden email]> wrote:




On Wed, May 21, 2014 at 2:58 PM, Eugenio Gianniti <[hidden email]> wrote:
Dear Marco, and all,

I attach the ufl.m function I have previously mentioned for review.

Thanks, really good job.
 
I still have to edit something, namely on line 45 a check for the .ufl file extension is performed with a case insensitive matching, but I should ensure with a couple more instructions that the lower case version is used, as in the functions that compile the .oct files for the problem at hand.

You should also check that we are not overwriting an existing file.

In this case it should error out complaining about the existing file and leaving it as it is, I would say. It is probably useful to add another command to delete a file and start from scratch, something like:
          >> ufl clear filename
or
          >> ufl rm filename
Do you agree?

 
There is also an issue due to a bug present in the stable version currently distributed, but solved in the development version. I also attach script.m, containing basically the Poisson.ufl of the homonymous example, but with ufl in first position. I noticed that my function works as I expect with the simpler lines, but Octave errors out when trying to execute the second and the ninth (I added comments to highlight those lines). This happens only in the stable release, on the other hand the development version goes on without complaining. Here is the error:

>> script
parse error near line 2 of file /Users/eugenio/tests/script.m

  syntax error

>>> ufl element = FiniteElement("Lagrange", triangle, 1)

How should I proceed with respect to this behaviour?

I don't have the stable version so I don't know how to reproduce it.
However it could be the "," as it is present only in this two lines.
But, as it has been fixed in the development version, probably someone here in the list can explain this behaviour. 

I am not really worried by this bug per se, in any case it has been solved in the development code, but my doubts are mainly:
      1) Should I look for the relevant bug report in the bug tracker and point out that this needs to be fixed also in the stable release? Or maybe just ask when it is scheduled to be included in it?
      2) Should I create a new branch to hold changesets related to this functionality, so that it does not make its way to the released package until the stable release of Octave allows it to work properly? I do not know what is the calendar you have in mind for fem-fenics releases, nor the main Octave’s, but it could be useful should the necessity arise.


Don't worry too much about it. We still have the import_ufl_Problem function which works on the stable function.
I was wondering if we should compile the code once the "end" command has been given, just to be sure that the code is correct and printing out the ffc error if it is not the case.
What do you think about it?

It can be a nice feature. I would also check for an argument given to the “ufl end” instruction to allow the choice of what is in the ufl snippet. I mean, I would let the user decide which one of the import_ufl_*.m s/he wants to use for that particular file.

 
Eugenio


Marco
Eugenio




The discussed edits are on the patch tracker:

Let me know if you find them good,
Eugenio
Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] ufl.m

Eugenio Gianniti

On 22 May 2014, at 16:13, Eugenio Gianniti <[hidden email]> wrote:


On 21 May 2014, at 17:29, Eugenio Gianniti <[hidden email]> wrote:


On 21 May 2014, at 17:00, Marco Vassallo <[hidden email]> wrote:




On Wed, May 21, 2014 at 4:33 PM, Eugenio Gianniti <[hidden email]> wrote:

On 21 May 2014, at 15:53, Marco Vassallo <[hidden email]> wrote:




On Wed, May 21, 2014 at 2:58 PM, Eugenio Gianniti <[hidden email]> wrote:
Dear Marco, and all,

I attach the ufl.m function I have previously mentioned for review.

Thanks, really good job.
 
I still have to edit something, namely on line 45 a check for the .ufl file extension is performed with a case insensitive matching, but I should ensure with a couple more instructions that the lower case version is used, as in the functions that compile the .oct files for the problem at hand.

You should also check that we are not overwriting an existing file.

In this case it should error out complaining about the existing file and leaving it as it is, I would say. It is probably useful to add another command to delete a file and start from scratch, something like:
          >> ufl clear filename
or
          >> ufl rm filename
Do you agree?

 
There is also an issue due to a bug present in the stable version currently distributed, but solved in the development version. I also attach script.m, containing basically the Poisson.ufl of the homonymous example, but with ufl in first position. I noticed that my function works as I expect with the simpler lines, but Octave errors out when trying to execute the second and the ninth (I added comments to highlight those lines). This happens only in the stable release, on the other hand the development version goes on without complaining. Here is the error:

>> script
parse error near line 2 of file /Users/eugenio/tests/script.m

  syntax error

>>> ufl element = FiniteElement("Lagrange", triangle, 1)

How should I proceed with respect to this behaviour?

I don't have the stable version so I don't know how to reproduce it.
However it could be the "," as it is present only in this two lines.
But, as it has been fixed in the development version, probably someone here in the list can explain this behaviour. 

I am not really worried by this bug per se, in any case it has been solved in the development code, but my doubts are mainly:
      1) Should I look for the relevant bug report in the bug tracker and point out that this needs to be fixed also in the stable release? Or maybe just ask when it is scheduled to be included in it?
      2) Should I create a new branch to hold changesets related to this functionality, so that it does not make its way to the released package until the stable release of Octave allows it to work properly? I do not know what is the calendar you have in mind for fem-fenics releases, nor the main Octave’s, but it could be useful should the necessity arise.


Don't worry too much about it. We still have the import_ufl_Problem function which works on the stable function.
I was wondering if we should compile the code once the "end" command has been given, just to be sure that the code is correct and printing out the ffc error if it is not the case.
What do you think about it?

It can be a nice feature. I would also check for an argument given to the “ufl end” instruction to allow the choice of what is in the ufl snippet. I mean, I would let the user decide which one of the import_ufl_*.m s/he wants to use for that particular file.

 
Eugenio


Marco
Eugenio




The discussed edits are on the patch tracker:

Let me know if you find them good,
Eugenio

On the patch tracker there is also a new patch correcting the help message [1], and you can find on my blog a post about the function [2].

Eugenio

Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] ufl.m

Marco Vassallo



On Fri, May 23, 2014 at 1:08 PM, Eugenio Gianniti <[hidden email]> wrote:


On the patch tracker there is also a new patch correcting the help message [1], and you can find on my blog a post about the function [2].


Hi Eugenio,
thanks for your blog post. The new ufl function does a great job.
You can update some of the examples on the wiki page accordingly, before starting a new part of your project.

I think that one of the main feature which is still missing in fem-fenics is the possibility of parallelizing the resolution of a problem. Please give a look at the documentation (Octave and Fenics) and propose some ideas on how we could address this issue. I haven't looked at the problem in deep yet, but I think that you have shown us to be good enough to deal with such an issue. Don't hesitate to ask for help here on the list and also on the FeniCs webmail.

Marco





 

Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] ufl.m

Eugenio Gianniti

On 24 May 2014, at 18:14, Marco Vassallo <[hidden email]> wrote:




On Fri, May 23, 2014 at 1:08 PM, Eugenio Gianniti <[hidden email]> wrote:


On the patch tracker there is also a new patch correcting the help message [1], and you can find on my blog a post about the function [2].


Hi Eugenio,
thanks for your blog post. The new ufl function does a great job.
You can update some of the examples on the wiki page accordingly, before starting a new part of your project.

Should I also move ufl code to the corresponding m-files of the examples in the package itself?

Eugenio


I think that one of the main feature which is still missing in fem-fenics is the possibility of parallelizing the resolution of a problem. Please give a look at the documentation (Octave and Fenics) and propose some ideas on how we could address this issue. I haven't looked at the problem in deep yet, but I think that you have shown us to be good enough to deal with such an issue. Don't hesitate to ask for help here on the list and also on the FeniCs webmail.

Marco





 


Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] ufl.m

Eugenio Gianniti
In reply to this post by Marco Vassallo

On 24 May 2014, at 18:14, Marco Vassallo <[hidden email]> wrote:




On Fri, May 23, 2014 at 1:08 PM, Eugenio Gianniti <[hidden email]> wrote:


On the patch tracker there is also a new patch correcting the help message [1], and you can find on my blog a post about the function [2].


Hi Eugenio,
thanks for your blog post. The new ufl function does a great job.
You can update some of the examples on the wiki page accordingly, before starting a new part of your project.

I updated Poisson and HyperElasticity on the wiki page [1], since NavierStokes has three ufl files, so the change would make the example almost unreadable. While at it I noticed that trailing whitespace prevents ufl files from compiling when it appears after a line continuation character, i.e. a backslash. I addressed the issue and provided a patch on the patch tracker [2].

When working on MixedPoisson I found out that ufl is not capable of writing to an ufl file a line such as:
           (sigma, u) = TrialFunctions(W)
This is due to the parser rules, since the corresponding Octave line is:
       >> ufl (sigma, u) = TrialFunctions(W)
where the first ufl (sigma, u) is interpreted as a call to a function, leading to a syntax error. I tried some possible solutions, like escaping brackets with a backslash or enclosing them in apices, but to no avail. After my attempts, I think that the only way to prevent the parsing error is to enclose both the brackets and their content in quotes or apices, like:
       >> ufl "(sigma, u)" = TrialFunctions(W)
This approach requires no further effort on the implementation side, but puts on users the burden of checking whether their ufl code has parentheses before an equal sign and edit it accordingly. I would proceed pointing out this issue in the help string for the ufl function, unless a more experienced developer comes out with advice on an alternative approach.

Eugenio



I think that one of the main feature which is still missing in fem-fenics is the possibility of parallelizing the resolution of a problem. Please give a look at the documentation (Octave and Fenics) and propose some ideas on how we could address this issue. I haven't looked at the problem in deep yet, but I think that you have shown us to be good enough to deal with such an issue. Don't hesitate to ask for help here on the list and also on the FeniCs webmail.

Marco





 


Reply | Threaded
Open this post in threaded view
|

[fem-fenics] Parallelism

Eugenio Gianniti
In reply to this post by Marco Vassallo

On 24 May 2014, at 18:14, Marco Vassallo <[hidden email]> wrote:




On Fri, May 23, 2014 at 1:08 PM, Eugenio Gianniti <[hidden email]> wrote:


On the patch tracker there is also a new patch correcting the help message [1], and you can find on my blog a post about the function [2].


Hi Eugenio,
thanks for your blog post. The new ufl function does a great job.
You can update some of the examples on the wiki page accordingly, before starting a new part of your project.

I think that one of the main feature which is still missing in fem-fenics is the possibility of parallelizing the resolution of a problem. Please give a look at the documentation (Octave and Fenics) and propose some ideas on how we could address this issue. I haven't looked at the problem in deep yet, but I think that you have shown us to be good enough to deal with such an issue. Don't hesitate to ask for help here on the list and also on the FeniCs webmail.

I am working on adding the OpenMP parallelisation paradigm to fem-fenics. I should, then, use the -fopenmp option to compile the oct-files. It turns out that mkoctfile only accepts a subset of the compiler flags that, for instance, g++ allows. In particular, all flags starting with -f are excluded. Is there an issue with such options preventing them to be passed to mkoctfile?

Eugenio


Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] ufl.m

Eugenio Gianniti
In reply to this post by Eugenio Gianniti

On 28 May 2014, at 15:34, Eugenio Gianniti <[hidden email]> wrote:


On 24 May 2014, at 18:14, Marco Vassallo <[hidden email]> wrote:




On Fri, May 23, 2014 at 1:08 PM, Eugenio Gianniti <[hidden email]> wrote:


On the patch tracker there is also a new patch correcting the help message [1], and you can find on my blog a post about the function [2].


Hi Eugenio,
thanks for your blog post. The new ufl function does a great job.
You can update some of the examples on the wiki page accordingly, before starting a new part of your project.

I updated Poisson and HyperElasticity on the wiki page [1], since NavierStokes has three ufl files, so the change would make the example almost unreadable. While at it I noticed that trailing whitespace prevents ufl files from compiling when it appears after a line continuation character, i.e. a backslash. I addressed the issue and provided a patch on the patch tracker [2].

When working on MixedPoisson I found out that ufl is not capable of writing to an ufl file a line such as:
           (sigma, u) = TrialFunctions(W)
This is due to the parser rules, since the corresponding Octave line is:
       >> ufl (sigma, u) = TrialFunctions(W)
where the first ufl (sigma, u) is interpreted as a call to a function, leading to a syntax error. I tried some possible solutions, like escaping brackets with a backslash or enclosing them in apices, but to no avail. After my attempts, I think that the only way to prevent the parsing error is to enclose both the brackets and their content in quotes or apices, like:
       >> ufl "(sigma, u)" = TrialFunctions(W)
This approach requires no further effort on the implementation side, but puts on users the burden of checking whether their ufl code has parentheses before an equal sign and edit it accordingly. I would proceed pointing out this issue in the help string for the ufl function, unless a more experienced developer comes out with advice on an alternative approach.

Here you can find the above mentioned patch:


Eugenio



I think that one of the main feature which is still missing in fem-fenics is the possibility of parallelizing the resolution of a problem. Please give a look at the documentation (Octave and Fenics) and propose some ideas on how we could address this issue. I haven't looked at the problem in deep yet, but I think that you have shown us to be good enough to deal with such an issue. Don't hesitate to ask for help here on the list and also on the FeniCs webmail.

Marco





 



Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] Parallelism

Marco Vassallo
In reply to this post by Eugenio Gianniti



On Thu, Jun 5, 2014 at 9:53 PM, Eugenio Gianniti <[hidden email]> wrote:

On 24 May 2014, at 18:14, Marco Vassallo <[hidden email]> wrote:




On Fri, May 23, 2014 at 1:08 PM, Eugenio Gianniti <[hidden email]> wrote:


On the patch tracker there is also a new patch correcting the help message [1], and you can find on my blog a post about the function [2].


Hi Eugenio,
thanks for your blog post. The new ufl function does a great job.
You can update some of the examples on the wiki page accordingly, before starting a new part of your project.

I think that one of the main feature which is still missing in fem-fenics is the possibility of parallelizing the resolution of a problem. Please give a look at the documentation (Octave and Fenics) and propose some ideas on how we could address this issue. I haven't looked at the problem in deep yet, but I think that you have shown us to be good enough to deal with such an issue. Don't hesitate to ask for help here on the list and also on the FeniCs webmail.

I am working on adding the OpenMP parallelisation paradigm to fem-fenics. I should, then, use the -fopenmp option to compile the oct-files. It turns out that mkoctfile only accepts a subset of the compiler flags that, for instance, g++ allows. In particular, all flags starting with -f are excluded. Is there an issue with such options preventing them to be passed to mkoctfile?

Please give a look at this post and see if it can be helpful [1].

HTH

Marco

 

Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] Parallelism

Marco Vassallo



On Thu, Jun 5, 2014 at 11:38 PM, Marco Vassallo <[hidden email]> wrote:



On Thu, Jun 5, 2014 at 9:53 PM, Eugenio Gianniti <[hidden email]> wrote:

On 24 May 2014, at 18:14, Marco Vassallo <[hidden email]> wrote:




On Fri, May 23, 2014 at 1:08 PM, Eugenio Gianniti <[hidden email]> wrote:


On the patch tracker there is also a new patch correcting the help message [1], and you can find on my blog a post about the function [2].


Hi Eugenio,
thanks for your blog post. The new ufl function does a great job.
You can update some of the examples on the wiki page accordingly, before starting a new part of your project.

I think that one of the main feature which is still missing in fem-fenics is the possibility of parallelizing the resolution of a problem. Please give a look at the documentation (Octave and Fenics) and propose some ideas on how we could address this issue. I haven't looked at the problem in deep yet, but I think that you have shown us to be good enough to deal with such an issue. Don't hesitate to ask for help here on the list and also on the FeniCs webmail.

I am working on adding the OpenMP parallelisation paradigm to fem-fenics. I should, then, use the -fopenmp option to compile the oct-files. It turns out that mkoctfile only accepts a subset of the compiler flags that, for instance, g++ allows. In particular, all flags starting with -f are excluded. Is there an issue with such options preventing them to be passed to mkoctfile?

Please give a look at this post and see if it can be helpful [1].


Hi Eugenio,

thanks for your new post. You should mention that the parallelism is not abandoned, but that the technical difficulties  encountered with OpenMP forced us to switch to MPI, which will be the second part of the GSOC.

Marco


Reply | Threaded
Open this post in threaded view
|

Re: [fem-fenics] Parallelism

Eugenio Gianniti

On 15 Jun 2014, at 12:55, Marco Vassallo <[hidden email]> wrote:




On Thu, Jun 5, 2014 at 11:38 PM, Marco Vassallo <[hidden email]> wrote:



On Thu, Jun 5, 2014 at 9:53 PM, Eugenio Gianniti <[hidden email]> wrote:

On 24 May 2014, at 18:14, Marco Vassallo <[hidden email]> wrote:




On Fri, May 23, 2014 at 1:08 PM, Eugenio Gianniti <[hidden email]> wrote:


On the patch tracker there is also a new patch correcting the help message [1], and you can find on my blog a post about the function [2].


Hi Eugenio,
thanks for your blog post. The new ufl function does a great job.
You can update some of the examples on the wiki page accordingly, before starting a new part of your project.

I think that one of the main feature which is still missing in fem-fenics is the possibility of parallelizing the resolution of a problem. Please give a look at the documentation (Octave and Fenics) and propose some ideas on how we could address this issue. I haven't looked at the problem in deep yet, but I think that you have shown us to be good enough to deal with such an issue. Don't hesitate to ask for help here on the list and also on the FeniCs webmail.

I am working on adding the OpenMP parallelisation paradigm to fem-fenics. I should, then, use the -fopenmp option to compile the oct-files. It turns out that mkoctfile only accepts a subset of the compiler flags that, for instance, g++ allows. In particular, all flags starting with -f are excluded. Is there an issue with such options preventing them to be passed to mkoctfile?

Please give a look at this post and see if it can be helpful [1].


Hi Eugenio,

thanks for your new post. You should mention that the parallelism is not abandoned, but that the technical difficulties  encountered with OpenMP forced us to switch to MPI, which will be the second part of the GSOC.


Right, I am writing other posts summarising the work of last week and stating what are the goals of the midterm and the final review, so I will point this out there. By this evening everything should be published.

Eugenio