[Users] meeting minutes for 2016-02-15

[Ian Hinder]

On 15 Feb 2016, at 17:04, Roland Haas <rhaas at aei.mpg.de> wrote:

> Present: Frank, Peter, Matt, Josh, Roland, Barry, Eloisa, Ian, Rahul
> 
> hwloc issues
> (http://lists.einsteintoolkit.org/pipermail/users/2016-February/004707.html):
> * Frank will look into them
> 
> Visualization software to use with Carpet data:
> * VisIt is currently the most mature support
> * experimental support in yt, but requires more work to make usable
> * currently output for 3d data is one file per process, changing to one
> file per timestep is not straightforward. See thread by
> http://lists.einsteintoolkit.org/pipermail/users/2016-January/004671.html
> 
> ExternalLibraries:
> * inconsistent user visible interface
> * rather want cosistent interface than new features for now
> * current implementation in bash in HDF5 is seen as a starting point,
> but all agree that having a language with more robust error control
> would be better (perl or python seem viable options)
> * all that want to contribute should look at the current bash code to
> decide which concepts to use and also if switching languages is the
> right thing to do. This should be done by next week's call.
> * (added after the call), keep in mind https://github.com/LLNL/spack and
> the discussion in
> http://lists.einsteintoolkit.org/pipermail/users/2016-January/004679.html as
> a possible long term or even currently available solution

Regarding the last point, I think we should keep in mind that the thorns in ExternalLibraries currently fulfil two functions.  The first is to provide a wrapper to an installed version of the library, and the second is to build and install the library itself.  The "spack" project, as well as the library features in simfactory 3, address the second function.  We would still need a common interface in ExternalLibraries for the first function, which should work whether the library is installed via Cactus or exists on the system independently.  For now, I would focus on this feature, rather than the build/install feature.

Note that there is also a wiki page with some ideas: https://docs.einsteintoolkit.org/et-docs/Improving_the_treatment_of_external_libraries.  

I'm not sure how much of this is already implemented in Frank's work.

One thing that occurs to me is that the current system might be "too clever", trying to automatically handle many use cases.  When looking at updating it, we might consider whether the code can be simplified by allowing just "automatic" or "manual" for each feature, where "automatic" works in very standard cases, but does not try too hard to work in every case.  I'm thinking of searching for libraries and headers etc. here.

-- 
Ian Hinder
http://members.aei.mpg.de/ianhin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20160215/f3a38ed2/attachment.html