octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fem-fenics] ufl.m


From: Eugenio Gianniti
Subject: Re: [fem-fenics] ufl.m
Date: Thu, 5 Jun 2014 19:59:37 +0000


On 28 May 2014, at 15:34, Eugenio Gianniti <address@hidden> wrote:


On 24 May 2014, at 18:14, Marco Vassallo <address@hidden> wrote:




On Fri, May 23, 2014 at 1:08 PM, Eugenio Gianniti <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]