Re: Package categories
On Monday 04 August 2008 13:58:51 Adam C Powell IV wrote:
> 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.
How about using a standard library's (those with shelves and dead-tree books)
classification system? This kind of problem should be solved by now, right?
There should be an easy way to import an ISO-like list of
categories/classes/tags. Anyone here knows a good librarian?
regards
FF
Reply to: