Re: Package categories
Felipe Figueiredo [EMAIL PROTECTED] writes: 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 [EMAIL PROTECTED] writes: [snip] 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? A friend of mine does - and this is what he says: Owen Massey wrote: On 6 Aug 2008, at 13:46, Dan Sheppard wrote: I don't know if you could help with this Debian question, Owen, using your 31337 classification skills? There's a category of engineering software which is getting rather large, and software often straddles categories, and are thinking of moving to some sort of faceted list from a taxonomy. The project seems to be looking for classifications (of whatever kind) from the world of library as a starting point. Though software itself might not be in (eg LCC [is this a QA thing or a T thing?], DCC), there might be a category of books dealing with the software, or perhaps there is a specialist software classification? A librarian writes: Traditional library classifications are built around books -- specifically, published books. So there is a slot for PDEs because there are lots of books about PDEs; there will be a slot for PDE solvers iff someone's written a book about PDE solvers. The Dewey classification failed to anticipate how important computing would become. Computer books are split between 'computer science' (generalities) and 'data processing' (technology). Most applications of computing -- that is, software programs -- have Dewey numbers constructed from the number for their function followed by 0285 for 'Computer applications', which doesn't add much in this case. The Library of Congress classification puts software in QA76.75 as a subclass of mathematics. I haven't used LCC in anger so I can't report how much detail there is in the subclassification. (There are other general library classifications but I don't believe any of them to be up to date.) Library classifications for specific fields exist and may help if they're publicly available: ACM Computing Classification Systemhttp://www.acm.org/class/ Mathematics Subject Classification http://www.ams.org/msc/ Physics and Astronomy Classification http://www.aip.org/pacs/ Engineering is much more fully developed than software in Dewey and LCC. Should the classification be by type of software or by subfield of engineering? Answer: yes. You're not limited online to a single classification point for a book. * * * That's *classification* dispensed with; perhaps more relevant to the problem at hand is *categorisation*. I believe computer scientists talk about 'taxonomies' and 'ontologies' where librarians talk about 'thesauri' and 'controlled vocabularies'. I suppose two things are important for the information architecture of the website: 1) controlled vocabulary: user looks for 'electromagnetics', you offer 'electromagnetism' 2) hierarchy: user looks for 'fluid dynamics', you offer 'fluid mechanics' (more general) or 'aerodynamics' (more specific) Library schemes are traditionally strong on 1) and weak on 2). Only categorisations which call themselves 'thesauri' have a fully-formed hierarchy. The joy, though, is that any object can and should have multiple categorisations. Have a look at Wikipedia's ad hoc but effective categorisation scheme. Then have a look at taxonomywarehouse.com. Most thesauri are developed for commercial bibliographic indexes and aren't readily available. The NASA Thesaurus covers engineering and is available free of charge (and presumably free of copyright as a US government publication), though only in PDF: http://www.sti.nasa.gov/98Thesaurus/vol1.pdf http://www.sti.nasa.gov/98Thesaurus/vol2.pdf * * * I'm not sure how much this helps: it may be using a sledgehammer to crack a nut. But please excerpt and redistribute as you see fit. Best, Owen -- To UNSUBSCRIBE, email to [EMAIL
Re: Package categories
Hi, Chris Walker [EMAIL PROTECTED] (2008-08-08 08:14:04) : Felipe Figueiredo [EMAIL PROTECTED] writes: 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? A friend of mine does - and this is what he says: [...] Do not hesitate to update the wiki page http://wiki.debian.org/DebianScience/Classification with relevant links and systems. Notice that this debate already showed up several times on this mailing list and that the answers are not obvious or controversial. I would advise to coordinate much with debtags people who have already thought a lot about this issues (hence the current naming of the metapackages inspired from the *existing* debtags). There is also some stuff around Wikipedia. My main motto: let's not reinvent the wheel. Best regards, Frédéric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
On Fri, 8 Aug 2008, Frederic Lehobey wrote: There is also some stuff around Wikipedia. My main motto: let's not reinvent the wheel. ACK. An please try to avoid making a science of it how to classify packages. It might be a really interesting topic but I would not be happy if this is overstressed here. We need something which works for our users and has to be understood by them. So please keep things simple here and filling *existing* packages into some useful categories. BTW, packages are no books that can only be put into one slot. One package can be inserted in more than one metapackage - so perhaps the whole discussion is way overdesigned. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
On Sat, 2008-08-02 at 19:28 +0100, Chris Walker wrote: Adam C Powell IV [EMAIL PROTECTED] 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/ signature.asc Description: This is a digitally signed message part
Re: Re: Package categories
On Sat, 2008-08-02 at 19:28 +0100, Chris Walker wrote: If there is an obvious set of tags, can you suggest them here. I've extended Adam's list a little bit. * 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 ...] * LP * ILP * MIP * combinatorial-optimization * combinatorial-geometry * finite-volumes * sparse-matrix-solver Do we have a Wiki to maintain these tags? Dominique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
On Mon, Jul 28, 2008 at 07:20:54PM -0430, Muammar El Khatib wrote: Are you sure about this? I mean as far as I have studied, DFT is not considered as Ab Initio (some people say yes, others no). Maybe calculation quality is as good as Ab Initio (DFT takes care about electronic correlation) but DFT starts from the premise that the electronic density is taken as the basic quantity. So the electronic density is the function taken for the functional (in this case the energy) while Ab Initio (like Hartree - Fock for instance) are based on the many-electron wavefunctions. On the other hand DFT uses parameters derived from _empirical data_, or from more complex calculations and in that moment is when DFT does not follow the calculations from first principles (where no empirical data is used). While you certainly have valid points concerning the classification of DFT vs. other methods from a scientific POV, what matters at hand is the classifaction for the user who wants to use Debian to do stuff. And at this level, DFT (at least talking from a computational chemistry point of view here) is identical to other ab-inito methods like MP2 or CCSD. Besides, how many empirical parameters you have depends on the particular exchange-correlation functional you use, in theory I think one can construct those functionals without using empirical parameters (see e.g. the PBE functional, Phys. Rev. Lett., 77, 3865). The very popular B3LYP functional indeed has a couple of them, but stil in this case you are doing an all-electron calculation if you choose so. The devide here is between ab-initio and semi-empirical - where the latter has a whole different dimension of empirical parameters it uses, and this is the useful destinction for users. cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
Adam C Powell IV [EMAIL PROTECTED] 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 * 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. 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. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
On Fri, 2008-08-01 at 11:02 +0100, Chris Walker wrote: Adam C Powell IV [EMAIL PROTECTED] writes: On Thu, 2008-07-24 at 13:44 +0100, Chris Walker wrote: Christophe Prud'homme [EMAIL PROTECTED] writes: Salome to my knowledge Salome does not provide a fe code ! AFAICT from http://www.salome-platform.org/home/presentation/overview/ while salome doesn't perform FEA calculations, it can be used to create meshes and display results from FEA - which is why I suggested it in that category. It wouldn't however fit in a numerical methods category. Indeed: Salomé proper doesn't include a solver, but it does just about everything else (meshing, MED file editing, post-processing). And Salomé-MECA adds modules to set up and monitor/control a complex Aster run, so in a sense it is a complete FEA front end. 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? * 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? 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... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Package categories
George Serbanut [EMAIL PROTECTED] writes: Hi everyone, May I ask you what version of DFT you want to put into the repository? (The DFT++ coming from Cornell?) That's because I am interested in getting it (I was thinking to install it myself). I used DFT to mean Density Functional Theory. There are several programs that perform calculations using this technique (including DFT++). Searching the unstable distribution for Density functional theory at http://packages.debian.org/ brings up the following packages which mention DFT: abinit, mpqc, openmx As far as I can tell, DFT++ is not packaged, and there is no ITP/RFP bug saying it will be packaged, or requesting that it be packaged. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
Felipe Figueiredo [EMAIL PROTECTED] writes: On Thursday 24 July 2008 03:29:00 Christophe Prud'homme wrote: === Finite Element Analysis === proposed -- field::physics:fea (it isn't clear to me that this should be in physics rather than engineering, so maybe field::fea would be better) In the particular example of FE, it's made in a Mathematics/Numerical Analysis framework, but most popularly used in Physics and Engineering. IMO, this is the core of this discussion. Does the tagging take into account the Field that uses the technique, or the one that makes/improves it? Maybe there should be some discussion in regard to policy to this matter, if there hasn't already been one. I'm not goint to debconf, but for those that are, perhaps they can discuss this in person - particularly with Enrico. A useful outcome would be a clear set of guidelines on how the current tags should be used. Ideally uploaded to the debtags wiki (and referenced from the DebianScience wiki) Another outcome is a list of possible further tags - or how to use the current tags to best effect[1]. Chris [1] A tag I'm wondering about is one that addresses the concept of dealing with crystal/molecular structure - molecular graphics packages do this along with visualisation, but so do things like various crystallography packages and EXAFS packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
Hi everyone, May I ask you what version of DFT you want to put into the repository? (The DFT++ coming from Cornell?) That's because I am interested in getting it (I was thinking to install it myself). Thanks! Cheers, George On Tue, Jul 29, 2008 at 2:50 AM, Muammar El Khatib [EMAIL PROTECTED] wrote: Hi, I'm sorry if maybe this would be a little bit off topic. However, I cannot talk to many people about Quantum mechanics :) So here I go. Michael Banck wrote: On Sun, Jun 29, 2008 at 07:03:58PM +0100, Chris Walker wrote: == Chemistry === field::chemistry === Structure calculation === Abinitio (should DFT be listed separately here? DFT is ab initio, despite all rumours. Are you sure about this? I mean as far as I have studied, DFT is not considered as Ab Initio (some people say yes, others no). Maybe calculation quality is as good as Ab Initio (DFT takes care about electronic correlation) but DFT starts from the premise that the electronic density is taken as the basic quantity. So the electronic density is the function taken for the functional (in this case the energy) while Ab Initio (like Hartree - Fock for instance) are based on the many-electron wavefunctions. On the other hand DFT uses parameters derived from _empirical data_, or from more complex calculations and in that moment is when DFT does not follow the calculations from first principles (where no empirical data is used). IMHO DFT should be listed separately. Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://teorex.org | http://taciturna.com ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
Hi, I'm sorry if maybe this would be a little bit off topic. However, I cannot talk to many people about Quantum mechanics :) So here I go. Michael Banck wrote: On Sun, Jun 29, 2008 at 07:03:58PM +0100, Chris Walker wrote: == Chemistry === field::chemistry === Structure calculation === Abinitio (should DFT be listed separately here? DFT is ab initio, despite all rumours. Are you sure about this? I mean as far as I have studied, DFT is not considered as Ab Initio (some people say yes, others no). Maybe calculation quality is as good as Ab Initio (DFT takes care about electronic correlation) but DFT starts from the premise that the electronic density is taken as the basic quantity. So the electronic density is the function taken for the functional (in this case the energy) while Ab Initio (like Hartree - Fock for instance) are based on the many-electron wavefunctions. On the other hand DFT uses parameters derived from _empirical data_, or from more complex calculations and in that moment is when DFT does not follow the calculations from first principles (where no empirical data is used). IMHO DFT should be listed separately. Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://teorex.org | http://taciturna.com ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
On Sun, 27 Jul 2008, Michael Banck wrote: On Sun, Jun 29, 2008 at 07:03:58PM +0100, Chris Walker wrote: === Structure calculation === Abinitio Semi Empirical === Molecular graphics === So we would have four categories for DebiChem? Certainly the chemistry stuff should get better sorted, and this is on my TODO list for debichem. In particular, the last group needs more grouping (molecular modelling, 2D structure editing etc.) ... or even more. At the same time, I am wondering why abinit got uploaded to pkg-scicomp without consulting the debichem team first? I'm a real fan of communication - so please be nice to each other and at least drop some notes to potentially interested groups ... If abinit is really only interesting to physicists I guess that's fine, but the description seems to indicate otherwise. Well, there is nothing that speaks against listing a package in more than one category (meta package). We know that we are listing DebiChem maintained packages in med-bio and there is much room for listing packages in more than one task. It seems pointless to have competing packaging groups around, Yes. As long as a package is solidly maintained there is no reason to blame anybody. I thought pkg-scicomp was mainly packaging software which is of general interest to scientific computing (like lapack, blas, etc.), not specific applications for which other packaging groups (and debian-science more generally) are already available. I admit that for me the role of pkg-scicomp is somehow unclear and the communication is not really the best. That's why we did not waited for the pkg-scicomp team to push the Debian Science effort but did this on our own and hope for a reasonable cooperation. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
On Sun, Jun 29, 2008 at 07:03:58PM +0100, Chris Walker wrote: == Chemistry === field::chemistry === Structure calculation === Abinitio (should DFT be listed separately here? DFT is ab initio, despite all rumours. Abinit (currently under physics) MPQC psi Semi Empirical mopac === Molecular graphics === Bkchem rasmol pymol Gabedit (possibly also referenced in abinitio) Chemtool garlic gchempaint grcystal Gdis jmol Certainly the chemistry stuff should get better sorted, and this is on my TODO list for debichem. In particular, the last group needs more grouping (molecular modelling, 2D structure editing etc.) At the same time, I am wondering why abinit got uploaded to pkg-scicomp without consulting the debichem team first? If abinit is really only interesting to physicists I guess that's fine, but the description seems to indicate otherwise. It seems pointless to have competing packaging groups around, I thought pkg-scicomp was mainly packaging software which is of general interest to scientific computing (like lapack, blas, etc.), not specific applications for which other packaging groups (and debian-science more generally) are already available. cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
On Thursday 24 July 2008 03:29:00 Christophe Prud'homme wrote: === Finite Element Analysis === proposed -- field::physics:fea (it isn't clear to me that this should be in physics rather than engineering, so maybe field::fea would be better) In the particular example of FE, it's made in a Mathematics/Numerical Analysis framework, but most popularly used in Physics and Engineering. IMO, this is the core of this discussion. Does the tagging take into account the Field that uses the technique, or the one that makes/improves it? Maybe there should be some discussion in regard to policy to this matter, if there hasn't already been one. regards FF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
=== Finite Element Analysis === proposed -- field::physics:fea (it isn't clear to me that this should be in physics rather than engineering, so maybe field::fea would be better) agreed or field::engineering::fea if field::engineering exists note that it could also fit in math / numerical methods for those who are interested in developing numerical methods in the codes below Exotk Code_Aster OpenFoam OpenFLOWer Salome to my knowledge Salome does not provide a fe code ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
On Thu, 2008-07-24 at 13:44 +0100, Chris Walker wrote: Christophe Prud'homme [EMAIL PROTECTED] writes: Salome to my knowledge Salome does not provide a fe code ! AFAICT from http://www.salome-platform.org/home/presentation/overview/ while salome doesn't perform FEA calculations, it can be used to create meshes and display results from FEA - which is why I suggested it in that category. It wouldn't however fit in a numerical methods category. Indeed: Salomé proper doesn't include a solver, but it does just about everything else (meshing, MED file editing, post-processing). And Salomé-MECA adds modules to set up and monitor/control a complex Aster run, so in a sense it is a complete FEA front end. Unfortunately, Salomé recent source code is not available, and most of -MECA source has never been released. :-( However, Sylvestre is in close contact with developers, and it looks like there will be progress by the end of the year. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Package categories
Le Thu, Jul 24, 2008 at 02:30:04PM +0100, Chris Walker a écrit : Is kst [A KDE application used for displaying scientific data] incorrectly tagged? In my opinion, yes. The drawback with Debtags is that tagging is anonymous, so we can't discuss with the person who tagged kst Field::Chemistry. But I would suggest asking the maintainer and CCing Debichem to confirm that this tag can be removed. Can someone explain the rationale for having both field::biology and biology::*. Unfortunately, they stem from a disagreement between me and the Debtags team. I wanted a Suite::EMBOSS and a few works-with and works-with-format tags related to biology, and they objected that it was too specialised. They created the biology::facet instead. I do not think that I want to use it. Here is the complete discussion. http://lists.alioth.debian.org/pipermail/debtags-devel/2007-September/001680.html I will go through the packages relevant to Debian Med and reopen the discussion with solid numbers about how many packages would use this or that proposed tag. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
Charles Plessy [EMAIL PROTECTED] writes: Le Sun, Jun 29, 2008 at 07:03:58PM +0100, Chris Walker a écrit : The debtags available don't seem to have quite enough granularity - but perhaps I've missed something - so I've knocked up a very incomplete list of sections that packages might drop into. Hi Chris, If I understand correctly, the Debtags are not granular on puropse. Better categorisation is supposed to be acheived by combining them. Yes. Furthermore, there are some programs that cross categories. For example, if one were to propose a tag Field::Crystallography [1], then that tag would be appropriate to molecular visualisation programs that had support for crystals - eg by allowing multiple unit cells etc. For instance Field::Chemistry, Use::Viewer instead of Field::Chemistry:Molecular grahpics. How does that distinguish it from the plotting program kst [2] - which is currently tagged Field::Chemistry and use::viewing Is kst incorrectly tagged? If not, should all the other scientific plotting programs be tagged chemistry too - or does kst have some chemistry specific features? This said, there are cases where creating subfacets are definitely the best solution. For instance for biology, we obtained the creation of the Field::Biology:molecular, :bioinformatics and :structural subfacets. As well as * biology::emboss: EMBOSS Packages related to the European Molecular Biology Open Software Suite. * biology::format:aln: Clustal/ALN Used in multiple alignment of biological sequences. * biology::format:fasta: Nexus Popular format for phylogenetic trees. * biology::nuceleic-acids: Nucleic Acids Software that works with sequences of nucleic acids: DNA, RNA but also non-natural nucleic acids such as PNA or LNA. * biology::peptidic: Proteins Software that works with sequences of aminoacids: peptides and proteins. Can someone explain the rationale for having both field::biology and biology::*. Chris [1] I do wonder about a field::cystallography - to encompas packages for real and reciprocal space study (X-ray, neutron and electron diffraction) of crystalline materials. [2] kst: A KDE application used for displaying scientific data This is a metapackage for kst which installs all of the relevant packages. kst is a program for examining data streams which can plot x-y plots, power spectra, histograms and equations (including equations of data streams). It can also be used to examine data in files which are being updated as data is being logged, in which case it can act as a plotter for a chart recorder. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
Le Sun, Jun 29, 2008 at 07:03:58PM +0100, Chris Walker a écrit : The debtags available don't seem to have quite enough granularity - but perhaps I've missed something - so I've knocked up a very incomplete list of sections that packages might drop into. Hi Chris, If I understand correctly, the Debtags are not granular on puropse. Better categorisation is supposed to be acheived by combining them. For instance Field::Chemistry, Use::Viewer instead of Field::Chemistry:Molecular grahpics. This said, there are cases where creating subfacets are definitely the best solution. For instance for biology, we obtained the creation of the Field::Biology:molecular, :bioinformatics and :structural subfacets. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
I agree with you, Adam. There are packages touching more than one subcategory. I am physicist in the elementary particle physics and high energies, working on software for that field, and I can say that, in my field at least, there cannot be physics without math and computer science. So, I support Adam in his comment. Cheers, George On Mon, Jun 30, 2008 at 5:39 AM, Adam C Powell IV [EMAIL PROTECTED] wrote: On Sun, 2008-06-29 at 13:55 +0100, Chris Walker wrote: It would be nice to see science packages better categorised. I guess this is ultimately best done using debtags. For example http://cdd.alioth.debian.org/science/tasks/physics.php lists packages to do Finite element analysis, optical simulation, xray absorption spectroscopy, ab inito quantum mechanics and computer algebra. I propose to post to this list or the wiki a list of potential subcategories along with packages that would go in them, and see where we go from there. Comments? Rather than subcategories, I would prefer keywords, because many packages cover multiple subcategories. But then, debtags are more keyword than (sub)category in this sense. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
Re: Package categories
On Sun, 29 Jun 2008, Chris Walker wrote: For example http://cdd.alioth.debian.org/science/tasks/physics.php lists packages to do Finite element analysis, optical simulation, xray absorption spectroscopy, ab inito quantum mechanics and computer algebra. I propose to post to this list or the wiki a list of potential subcategories along with packages that would go in them, and see wheres we go from there. The current technique to build these pages is not able to create subcategories and there is no plan to add this feature for reasons given below. I would not recommend using a wiki for the categorisation - other CDDs had the experience that these wikis become unmaintained and outdated very quickly. PS I think that http://cdd.alioth.debian.org/science/tasks/physics.php is nice, but a denser format would also be useful - more like the https://help.ubuntu.com/community/UbuntuScience (but again with better subcategories). I perfectly agree that physical packages deserve a better categorisation. DebTags is great and should definitely be used - just go for a tagging of these packages. The reason why we do not have a better categorisation is that we started Debian Science CDD for those sciences that did not yet have enough man power to maintain an own CDD. I would really love to see a Debian Physics CDD. Would you volunteer to care for this? My suggestion would be to start with creating tasks files builded according to the known sheme and move them to the cdd/projects space. Then we could build physics specific pages easily and will see whether this idea attracts enough people to work on a self-contained CDD. Just ask if you need any help. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
On Sun, Jun 29, 2008 at 04:30:35PM +0200, Andreas Tille wrote: On Sun, 29 Jun 2008, Chris Walker wrote: For example http://cdd.alioth.debian.org/science/tasks/physics.php lists packages to do Finite element analysis, optical simulation, xray absorption spectroscopy, ab inito quantum mechanics and computer algebra. I propose to post to this list or the wiki a list of potential subcategories along with packages that would go in them, and see wheres we go from there. The current technique to build these pages is not able to create subcategories and there is no plan to add this feature for reasons given below. I would not recommend using a wiki for the categorisation - other CDDs had the experience that these wikis become unmaintained and outdated very quickly. It was the outdatedness of the science wiki pages that prompted me to think something needs doing, and that there was a contribution I could make. The other thing was seeing some discussion about FEA packages going in - but it not being clear whether there was a complete fea system I would be able to use. PS I think that http://cdd.alioth.debian.org/science/tasks/physics.php is nice, but a denser format would also be useful - more like the https://help.ubuntu.com/community/UbuntuScience (but again with better subcategories). I perfectly agree that physical packages deserve a better categorisation. DebTags is great and should definitely be used - just go for a tagging of these packages. I'm not sure there are enough categories - physics is too coarse a granularity - perhaps I should post some examples. The reason why we do not have a better categorisation is that we started Debian Science CDD for those sciences that did not yet have enough man power to maintain an own CDD. I would really love to see a Debian Physics CDD. Would you volunteer to care for this? I don't think I will have the time unfortunately. In addition, although I'm a physicist, much of what I've done has been crystallography, so packages useful to me would pull in a significant part of chemistry. My suggestion would be to start with creating tasks files builded according to the known sheme and move them to the cdd/projects space. Then we could build physics specific pages easily and will see whether this idea attracts enough people to work on a self-contained CDD. Just ask if you need any help. I'll list some tasks and packages, and see where we go from there. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
On Sun, Jun 29, 2008 at 05:46:23PM +0100, chrisw wrote: On Sun, Jun 29, 2008 at 04:30:35PM +0200, Andreas Tille wrote: On Sun, 29 Jun 2008, Chris Walker wrote: For example http://cdd.alioth.debian.org/science/tasks/physics.php lists packages to do Finite element analysis, optical simulation, xray absorption spectroscopy, ab inito quantum mechanics and computer algebra. I propose to post to this list or the wiki a list of potential subcategories along with packages that would go in them, and see wheres we go from there. And here it is. == Overview == I find that categorising packages into just physics/chemistry/maths is not quite granular enough. It would be nice to have better granularity - and I think that debtags is probably the way to go here. What do other people think? The debtags available don't seem to have quite enough granularity - but perhaps I've missed something - so I've knocked up a very incomplete list of sections that packages might drop into. Nb all the packages here have been packaged for debian. I guess the main thing I'm aiming for is some discussion of whether there is need for addition package tags, or perhaps I've missed something. Comments? == Physics == field::physics === Finite Element Analysis === proposed -- field::physics:fea (it isn't clear to me that this should be in physics rather than engineering, so maybe field::fea would be better) Exotk Code_Aster OpenFoam OpenFLOWer Salome === Diffraction/crystal structure solution === (all the below are listed as having unofficial packages by Carlo Segre). mpr peak fitting and x-ray diffraction data viewer expgui GUI for GSAS (OK for Debian but GSAS isn't) fox crystal structure solution mcmaille x-ray structure solution tpf x-ray profile refinement xgen macromolecular crystallography === Particle Physics === CERNLIB == Chemistry === field::chemistry === Structure calculation === Abinitio (should DFT be listed separately here? Abinit (currently under physics) MPQC psi Semi Empirical mopac === Molecular graphics === Bkchem rasmol pymol Gabedit (possibly also referenced in abinitio) Chemtool garlic gchempaint grcystal Gdis jmol == Maths == ===Symbolic calculation === maxima ===Matlab like === octave pdl matplotlib scilab == Data Acquisition == libcomedi libgpib -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package categories
On Sun, 2008-06-29 at 13:55 +0100, Chris Walker wrote: It would be nice to see science packages better categorised. I guess this is ultimately best done using debtags. For example http://cdd.alioth.debian.org/science/tasks/physics.php lists packages to do Finite element analysis, optical simulation, xray absorption spectroscopy, ab inito quantum mechanics and computer algebra. I propose to post to this list or the wiki a list of potential subcategories along with packages that would go in them, and see where we go from there. Comments? Rather than subcategories, I would prefer keywords, because many packages cover multiple subcategories. But then, debtags are more keyword than (sub)category in this sense. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
