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

Re: Package categories



On Sat, 2008-08-02 at 19:28 +0100, Chris Walker wrote:
> Adam C Powell IV <hazelsct@debian.org> writes:
> 
> > On Fri, 2008-08-01 at 11:02 +0100, Chris Walker wrote:
> > > And http://www.opennovation.org/ provides a much better categorisation
> > > of engineering type packages than I did.
> > > 
> > > Categories there are:
> > > 
> > > Partial Differential Equation (PDE) Solvers
> > >         General Finite Element Analysis (FEA)
> > >         Computational Fluid Dynamics (CFD)
> > >         Electromagnetism and Optics
> > >         Software for Phase Field simulations
> > >         Boundary Element Method (BEM)
> > > 
> > >         Pre- and post-processing frameworks and tools
> > > 
> > > 
> > > Computer-Aided Design (CAD)
> > > 
> > > Multi-body dynamics
> > > 
> > > Integrated Computational Materials Engineering (ICME)
> > >  (Ab initio and Molecular dynamics codes listed here)
> > 
> > As the owner/maintainer of opennovation.org, I'm struggling with this
> > categorization, and welcome input.  For example:
> >       * Is libMesh FEA or CFD?  It is a general FEA lib, but its
> >         examples and development point toward CFD -- not to mention that
> >         its authors are the CFD group at UT Austin.  Saturne is clearly
> >         CFD and Aster is clearly mechanics/heat (as are CacluliX and
> >         Impact), so why should Aster, CalculiX and Impact be in general
> >         FEA?
> I've got as far as bending a beam using FEA, so take this with some
> pinches of salt.
> 
> Would listing all the programs in one PDE solvers in one category, but
> having "ticks" for CFD, mechanics, etc solve the problem - these would
> correspond naturally to tags.
> 
> Eg:
> 
> CFD |  Mechancics | Integrated pre/post  |  
>  x  |      x      |                      |  Prog1
>  x  |             |          x           |  Prog 2

Excellent idea.  Makes for a big table though, once you start listing
all of the interesting capabilities.  I have the beginnings of such a
beast (going through a transition) at:
http://www.opennovation.org/fea.html

(Posting this here will motivate me to work on finishing it. :-)

> >       * Should libraries be treated differently from standalone codes?
> >         Or is input file vs. short program which calls the library
> >         functions merely a semantics issue?  Aster calls its python
> >         scripts "input files" where FiPy calls the exact same thing
> >         "programs which call its functions".
> >       * How about "standalone" FEA codes like Aster, vs. an integrated
> >         pre- post- and solver like OpenFOAM?
> 
> If you like the idea above, then have an Integrated pre/post solver
> "tick". 
> 
> You could then have a "separated pre/post processor". Knowing which
> pre/post processor works with which codes will also help.

Indeed!

> > These are some of the reasons I think keywords or tags are more
> > appropriate than "categories".  But keywords/tags don't lend themselves
> > to well-organized websites...
> 
> If there is an obvious set of tags, can you suggest them here.

Okay, here's a start:
      * PDE-solver
      * finite-elements
      * boundary-elements
      * finite-differences
      * integrated-mesher
      * integrated-visualization
      * fluid-dynamics
      * solid-mechanics
      * heat-mass-transfer
      * radiation
      * electromagnetics
      * multi-domain
      * multi-thread
      * MPI
      * PVM
      * works-with [Salomé | gmsh | VTK ...]

This list can grow arbitrarily if we let it.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: