all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Adding Trilinos to dealii package
@ 2021-05-21 12:36 Paul A. Patience
  2021-05-23  5:19 ` Arun Isaac
  0 siblings, 1 reply; 5+ messages in thread
From: Paul A. Patience @ 2021-05-21 12:36 UTC (permalink / raw)
  To: guix-devel@gnu.org

Hi,

I would like to eventually package the Lethe CFD library [1], but it
requires a version of dealii compiled with Trilinos, which is not
currently available in Guix.

PETSc and Trilinos (and many other libraries available in Guix) can be
compiled with several different options.
What is the standard way to deal with this in Guix?
From what I can tell, in general the packages get a reasonable default
and people who require different options make a channel and inherit from
the base package, and in some really practical cases we get a variant of
the package with a similar name, e.g., dealii-openmpi.

The potential problem with PETSc and Trilinos when it comes to dealii is
that some of the optional modules they can be compiled with are the
same, which causes trouble when dealii is configured with both of
them [2].
(From what I can tell, the module in question is not configured in the
Guix package for PETSc, so this point may be moot.)

I'm wondering what the best way would be to add Trilinos to the dealii
packages (assuming I manage to package Trilinos as well).
In other words, which would be best among the following:

- Build Trilinos with a reasonable configuration for dealii [3] and
  update the dealii and dealii-openmpi packages to include it (if the
  problem mentioned above turns out not to be an issue).
  This assumes people won't mind having to build Trilinos as a
  dependency for dealii even if they don't need it.

- Build Trilinos as above but add separate packages for the resulting
  dealii, e.g., dealii-trilinos, dealii-trilinos-openmpi.
  This seems like it would get awkward quite quickly, which is why
  assuming my thoughts on the purposes of channels are correct, this is
  the inferior option.

- Abandon all hope and just maintain a channel for dealii configured
  with Trilinos (the inferiorer option :)).

- Some other possibility I have not thought of.

Thank you and best regards,
Paul

[1]: https://github.com/lethe-cfd/lethe
[2]: https://www.dealii.org/current/external-libs/petsc.html
[3]: https://www.dealii.org/current/external-libs/trilinos.html



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Adding Trilinos to dealii package
  2021-05-21 12:36 Paul A. Patience
@ 2021-05-23  5:19 ` Arun Isaac
  0 siblings, 0 replies; 5+ messages in thread
From: Arun Isaac @ 2021-05-23  5:19 UTC (permalink / raw)
  To: Paul A. Patience, guix-devel@gnu.org

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]


Hi Paul,

> PETSc and Trilinos (and many other libraries available in Guix) can be
> compiled with several different options.
> What is the standard way to deal with this in Guix?

Normal Guix policy is as follows. If adding extra dependencies does not
significantly increase the size of the package (as reported by `guix
size <package>`), then we proceed with that. If it increases the size
significantly, then we may consider adding separate packages (such as
dealii-trilinos, etc.).

Hope that helps! :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 524 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Adding Trilinos to dealii package
@ 2021-05-23 12:40 zimoun
  2021-05-24 17:04 ` Leo Famulari
  0 siblings, 1 reply; 5+ messages in thread
From: zimoun @ 2021-05-23 12:40 UTC (permalink / raw)
  To: Paul A. Patience, Guix Devel

Hi,

> PETSc and Trilinos (and many other libraries available in Guix) can be
> compiled with several different options.
> What is the standard way to deal with this in Guix?

AFAIK, there is no concrete standard way.  Only what explained Arun. ;-) 

> The potential problem with PETSc and Trilinos when it comes to dealii is
> that some of the optional modules they can be compiled with are the
> same, which causes trouble when dealii is configured with both of
> them [2].
> (From what I can tell, the module in question is not configured in the
> Guix package for PETSc, so this point may be moot.)

What I miss is: Trilinos is somehow a replacement of PETSc.  You would
like Deal.II compiled with both Trilinos *and* PETSc support, right?

> I'm wondering what the best way would be to add Trilinos to the dealii
> packages (assuming I manage to package Trilinos as well).

FWIW, I would start by package Trilinos. ;-)

> - Some other possibility I have not thought of.

IIUC, your question is how Guix deals with “package parameters“, right?
And the answer is: it is complicated. ;-)

First, I do not know if it is worth to have many variants in Guix
proper.  There is 2 things to consider: a) how complicated the recipe of
the variant is?  and b) how much resource (CPU, RAM, etc.) does the
variant require to be built?  Somehow, if the recipe is simple enough,
by simply apply package transformation (say), and if it can be built on
a powerless laptop (say), then the variant does not worth, IMHO.  Else,
it is an open discussion. ;-)

Second, I would like to mention the guix-science@gnu.org mailing list
where this kind of questions are sometimes discussed.  And
hpc.guix.info/about lists scientific channels where the workload could
be shared.

Hope that helps,
simon


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Adding Trilinos to dealii package
  2021-05-23 12:40 zimoun
@ 2021-05-24 17:04 ` Leo Famulari
  0 siblings, 0 replies; 5+ messages in thread
From: Leo Famulari @ 2021-05-24 17:04 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel, Paul A. Patience

On Sun, May 23, 2021 at 02:40:04PM +0200, zimoun wrote:
> Hi,
> 
> > PETSc and Trilinos (and many other libraries available in Guix) can be
> > compiled with several different options.
> > What is the standard way to deal with this in Guix?
> 
> AFAIK, there is no concrete standard way.  Only what explained Arun. ;-) 

And we should also consider the utility of the package. If it's not
useful without some large dependency, or typically used with that
dependency, then we don't need to make separate packages.

In general, it's a matter of judgment.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Adding Trilinos to dealii package
@ 2021-05-24 17:53 Paul Garlick
  0 siblings, 0 replies; 5+ messages in thread
From: Paul Garlick @ 2021-05-24 17:53 UTC (permalink / raw)
  To: paul, guix-devel

Dear Paul,

> I would like to eventually package the Lethe CFD library

Nice!

Trilinos has many bells and whistles. I imagine that there will be some
significant effort required to package it.  One option would be to
subdivide the library and initially package only the elements you need
for Lethe.  See the Debian approach to packaging Trilinos for example
[1].

If Lethe does not use PETSc there would be no risk of conflict.  The
choice between including the new Trilinos (sub)package as a dependency
of dealii and dealii-openmpi or creating new dealii-trilinos and
dealii-trilinos-openmpi packages would be marginal.  How many models
need to use PETSc and Trilinos at the same time?

> This assumes people won't mind having to build Trilinos as a
> dependency for dealii even if they don't need it.

The model run times are usually very much longer than the library build
times.  I expect this would be true for Trilinos and Lethe too.

Best regards,

Paul.

[1]: https://packages.debian.org/source/buster/trilinos



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-05-24 17:54 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-05-24 17:53 Adding Trilinos to dealii package Paul Garlick
  -- strict thread matches above, loose matches on Subject: below --
2021-05-23 12:40 zimoun
2021-05-24 17:04 ` Leo Famulari
2021-05-21 12:36 Paul A. Patience
2021-05-23  5:19 ` Arun Isaac

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.