Subject: [FEniCS-dev] FEniCS'06 post-mortem

From: Johan Jansson <[email-masked]>
Date: Mon, 13 Nov 2006 14:21:57 +0100

Hi all,

The FEniCS'06 workshop was very successful: many interesting
discussions came up, problems were overcome and new plans were made. I
also had a good time personally, and it seemed like everyone else did
as well.

I realize organizing a good conference is often unappreciated work.
But I think most people are aware that Garth provided the initial
conditions for the conference, so to speak, and had a hand in
essentially everything that happened. So in this case it's much
appreciated work, which I hope we'll be able to repay in kind in the
future.

Garth mentioned at the end that it would be good to make a concrete
plan of all the things that came up. I think this is a good idea, and
it would be good if people could write down and post their plans while
it's still fresh.

  Johan

---

From: "Johan Hoffman" <[email-masked]>
Date: Mon, 13 Nov 2006 15:49:26 +0100 (MET)

I agree with Johan; Garth was a top host! I had a great time, and I got
back to Sweden without having been run over!

Some things that came up, which we should pursue in one way or another:

* Dolfin: surface integration (boundary + internal for discontinuous
Galerkin etc.)
* Dolfin mesh: hierarchical vs single mesh mode (geometric vs algebraic
multigrid): support both.
* Dolfin mesh: refinement/coarsening: reimplementation of broken
Bey-algorihtm, test of "Matt-algorithm", test of simple split/collapse
algorithms + smoothing/flipping.
* DOLFIN: Full adaptive Navier-Stokes solver to be implemented (today
primal solver + broken mesh refinement in place)
* DOLFIN: Compressible flow module
* Dolfin: ALE + free surface modules
* Dolfin/FFC: automatic generation of error estimate/mesh indicators
* Dolfin build system: Scons or Cmake...
* Dolfin/FFC bc: assembly of strong bc directly in FFC (together with weak
implementation)
* dolfin-dev + dolfin-stable
* Dolfin license: there seems to be an agreement on GPL -> LGPL

/Johan

> _______________________________________________
> FEniCS-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/fenics-dev
>

---

From: Anders Logg <[email-masked]>
Date: Thu, 16 Nov 2006 23:34:48 +0100

Let me add a few items:

 - "Parallelization" of the mesh

 - Finish UFC specification 1.0

 - Move FFC to UFC

 - New build system

 - BDM, RT elements in FFC

 - DG in FFC (jump terms etc)

 - Design and implement UFL

 - Move FFC to UFL and integrate UFL in DOLFIN/PyDOLFIN

/Anders

---

From: Andy Ray Terrel <[email-masked]>
Date: Thu, 16 Nov 2006 23:26:50 -0600

So people mentioned about the five minute attention span for building a 
system.  We did mention running a web service that might be able to 
help, such a feature is available through the Trilinos package but I 
haven't asked them how much it really is a bonus.

Another idea I have seen in growing popularity is to manage a wiki.  It 
would allow people to put up how things work more and give others the 
opportunity to look for more information.  I have actually never managed 
one of these things so I don't know how much work it would be.

--Andy

-- 

====================
Andy Terrel
Computer Science Dept
University of Chicago
[email-masked]
---------------------

Flying is simple. 
You just throw yourself at the ground and miss.
              -Hitchhiker's Guide to the Galaxy

---

From: Anders Logg <[email-masked]>
Date: Fri, 17 Nov 2006 11:20:08 +0100

> haven't asked them how much it really is a bonus.

This would be good to have. For example, people could input an FFC
form and get the generated code in return. This is ideal for a web
service since we have a simple model for what comes in and what comes
out. The problem would be that the FFC form is Python code, so the web
service would execute arbitrary Python code that someone enters into
the web form. So there are security issues.

> one of these things so I don't know how much work it would be.

This would also be good to have, if someone is willing to maintain it.

/Anders

---

From: Mandus <[email-masked]>
Date: Fri, 17 Nov 2006 11:41:27 +0100

> the web form. So there are security issues.

The secuity issues can be tackled by using virtualization, maybe even using
a readonly virtual disk. Not that it is very easy to put together but
absolutely doable. There are other sandbox-based approaches that can be used
as well.

> This would also be good to have, if someone is willing to maintain it.

The hard part with a Wiki is probably  to get the community to write stuff
into the Wiki. You need some momentum to get it going. If only the main
developers will write stuff into it anyway, we are maybe better off without
the hassle, the developers already have (or can have) access to write on the
static pages. I think we should only consider a Wiki if we expect people
from the outside world to write.

/Anders

-- 
Mandus
The only dr. Mandus around.

---

From: "Matthew Knepley" <[email-masked]>
Date: Fri, 17 Nov 2006 04:28:13 -0600

> the web form. So there are security issues.

This is not the big problem here I think (Python has an rshell). Whenever you
distribute code (generated or not) you implicitly rely on a sahred
body of support
code. This is exactly the problem with Java. Its relied heavily on the libraries
rather than just the machine. I cannot yet see how we could generate something
that was usable apart from the FEniCS framework, in which case the user was
able to install, so why have a webform at all?

   Matt

-- 
"Failure has a thousand explanations. Success doesn't need one" -- Sir
Alec Guiness

---

From: Anders Logg <[email-masked]>
Date: Fri, 17 Nov 2006 13:23:51 +0100

> able to install, so why have a webform at all?

Good point. The code currently generated by FFC contains a large
number of #include <dolfin/...>. The next version of FFC will generate
UFC code that will not depend on anything other than the UFC
specification which is just one file (that could be thrown into the
generated code).

Still, the user would need to write the assembly-code so the support
code must be there anyway.

/Anders

---

From: Johan Jansson <[email-masked]>
Date: Fri, 17 Nov 2006 13:31:59 +0100

On Fri, Nov 17, 2006 at 04:28:13AM -0600, Matthew Knepley wrote:

> This is not the big problem here I think (Python has an
> rshell). Whenever you distribute code (generated or not) you
> implicitly rely on a sahred body of support code. This is exactly
> the problem with Java. Its relied heavily on the libraries rather
> than just the machine. I cannot yet see how we could generate
> something that was usable apart from the FEniCS framework, in which
> case the user was able to install, so why have a webform at all?

Yes, I'm thinking along these lines as well. If we have virtual
machines as a possibility, then why not simply provide public shell
access to an installed FEniCS environment in an isolated sandbox?

We could have a web form where you can define a form and coefficients,
and which then solves the equation and plots the solution, but I'm not
really sure if that would target the correct audience.

  Johan

---

From: "Theodore Omtzigt" <[email-masked]>
Date: Fri, 17 Nov 2006 09:06:10 -0500

I can donate a machine and the elbow grease to maintain it. I was thinking
to use Confluence from Atlassian for our internal documentation. If folks
are ok with that look and feel, I can start the process of setting up the
wiki.

Theo

P.S. I just saw Mandus's issue regarding outside folks. I would argue that a
wiki is valuable even if only developers contribute. Folks have starting to
expect a wiki interface to documentation. It simply enhances the image of
FEniCS as a project that is "with it". 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Anders Logg
Sent: Friday, November 17, 2006 5:20 AM
To: [email-masked]
Subject: Re: [FEniCS-dev] FEniCS'06 post-mortem

/Anders

---

From: 'Anders Logg' <[email-masked]>
Date: Fri, 17 Nov 2006 15:28:54 +0100

I have never heard of Confluence. Is it free?

/Anders

---

From: "tomtzigt" <[email-masked]>
Date: Thu, 23 Nov 2006 08:20:24 -0500

One other way to think about FEniCS is as a problem solving environment and
the web application as a possible public PSE interface. The form would be
one aspect of the application as would be a visualization/result query
interface, but all the processing FEniCS does would execute on the server
side.

Having built two such systems, the work involved is non-trivial and would be
an additional drain on development resources. On top of that, it comes with
its own build and release headaches. Even though I love that kind of
architecture, and feel it would be something we should put on the list, I
don't think this would be the time to do it.

Theo

  Johan