[Insight-developers] check-in the FEM classes in itk

Wed, 21 Nov 2001 16:13:49 -0500

--=====================_8131973==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

>
>We're planning to check-in the first pre-alpha version of the Finite 
>Element Modeling (FEM) code by the end of the next week. We'll be adding a 
>lot of new files (>50) and classes into the toolkit and I really don't 
>want to screw something up while doing this.
>

This is exciting news...a great addition to the toolkit. Thanks for 
worrying about screwing up ;-)

Generally the classes you add may end up in separate directories, I would 
prefer not to add a new FEM directory unless that makes sense (yes, a FEM 
example does make sense in Insight/Examples). Certainly the ones used the 
most, or that have general utility, belong in Common or BasicFilters. The 
more specialized filters and such probably belong in Algorithms.

The bottom line for you guys seems to be managing dependencies, especially 
as they relate to the numerical solver. I'm hoping that you guys have set 
things up so that this can be easily replaced .... i.e. is modular. (We 
talked to Jim Gee about creating a generic front end/wrapper for vnl or any 
other solver that is used. Vnl won't handle the sparse matrix stuff, but 
the front end would handle that and transform the data to fit vnl. On other 
systems, the front end might just pass the data through naturally to the 
sparse solver. The default behavior would be to use Vnl with its wrapper 
classes since it is always built as part of the system. More advanced users 
could download and install the preferred solver and then setup the build 
with CMake.)

I suggest that you package up your source (as it is now-don't go to any 
trouble-zip or compress it) and post it to the list. Then we can peek at 
the code and help make some decisions about where the code should end up.

Don't worry about the regions for now. I assume that you are using itk::Mesh ?

Will

At 03:37 PM 11/21/2001 -0500, Aljaz Noe wrote:
>Hi!
>
>So, can you give me some guidelines on how to import some new code into 
>itk toolkit? Currently our FEM code is not a part of itk, but only uses 
>the itk via the #include statements. How do we make our files a part of 
>itk, that will compile as expected when checked out with the rest of the 
>itk? Here I'm particularly interested about what to do with CMake.
>
>Where do we put the files? Do we get a separate folder (called FEM???), or 
>should we dump everything in the common folder?
>
>Is it possible (allowed?) to use another namespace within the itk 
>namespace to mask internally used classes? Since the FEM toolkit was 
>originally developed independently of itk, we currently use quite a few of 
>them, and they really serve no purpose outside the FEM framework.
>
>What is the status of LightDataObject (or whatever it's called), which 
>doesn't have regions? Most of the Data Objects that we use don't have 
>regions. It makes little sense to, for example, apply only half of the 
>prescribed boundary conditions or material properties to the system. It 
>would be nice if we all use the same base classes (if they exist) to 
>create corresponding data and process objects.
>
>Any other comments that you may have, are of course appreciated...
>
>Aljaz
>

--=====================_8131973==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<blockquote type=cite class=cite cite>&nbsp; 
We're planning to check-in the first pre-alpha
version of the Finite Element Modeling (FEM) code by the end of the next
week. We'll be adding a lot of new files (&gt;50) and classes into the
toolkit and I really don't want to screw something up while doing
this. 
&nbsp;</blockquote> 
This is exciting news...a great addition to the toolkit. Thanks for
worrying about screwing up ;-) 
 
Generally the classes you add may end up in separate directories, I would
prefer not to add a new FEM directory unless that makes sense (yes, a FEM
example does make sense in Insight/Examples). Certainly the ones used the
most, or that have general utility, belong in Common or BasicFilters. The
more specialized filters and such probably belong in Algorithms. 
 
The bottom line for you guys seems to be managing dependencies,
especially as they relate to the numerical solver. I'm hoping that you
guys have set things up so that this can be easily replaced .... i.e. is
modular. (We talked to Jim Gee about creating a generic front end/wrapper
for vnl or any other solver that is used. Vnl won't handle the sparse
matrix stuff, but the front end would handle that and transform the data
to fit vnl. On other systems, the front end might just pass the data
through naturally to the sparse solver. The default behavior would be to
use Vnl with its wrapper classes since it is always built as part of the
system. More advanced users could download and install the preferred
solver and then setup the build with CMake.) 
 
I suggest that you package up your source (as it is now-don't go to any
trouble-zip or compress it) and post it to the list. Then we can peek at
the code and help make some decisions about where the code should end
up. 
 
Don't worry about the regions for now. I assume that you are using
itk::Mesh ? 
 
Will 
 
At 03:37 PM 11/21/2001 -0500, Aljaz Noe wrote: 
<blockquote type=cite class=cite cite>Hi! 
 
So, can you give me some guidelines on how to
import some new code into itk toolkit? Currently our FEM code is not a
part of itk, but only uses the itk via the #include statements. How do we
make our files a part of itk, that will compile as expected when checked
out with the rest of the itk? Here I'm particularly interested about what
to do with CMake. 
&nbsp; 
Where do we put the files? Do we get a separate
folder (called FEM???), or should we dump everything in the common
folder? 
&nbsp; 
Is it possible (allowed?) to use another
namespace within the itk namespace to mask internally used classes? Since
the FEM toolkit was originally developed independently of itk, we
currently use quite a few of them, and they really serve no purpose
outside the FEM framework. 
&nbsp; 
What is the status of LightDataObject (or
whatever it's called), which doesn't have regions? Most of the Data
Objects that we use don't have regions. It makes little sense to, for
example, apply only half of the prescribed boundary conditions or
material properties to the system. It would be nice if we all use the
same base classes (if they exist) to create corresponding data and
process objects. 
&nbsp; 
Any other comments that you may have, are of
course appreciated... 
&nbsp; 
Aljaz 
&nbsp;</blockquote></html>

--=====================_8131973==_.ALT--