[PATCH] gnu: openfoam: Clean up to reduce closure.

  • Done
  • quality assurance status badge
Details
3 participants
  • Dave Love
  • Ludovic Courtès
  • Paul Garlick
Owner
unassigned
Submitted by
Dave Love
Severity
normal
D
D
Dave Love wrote on 25 Sep 2017 12:44
(address . guix-patches@gnu.org)(name . Dave Love)(address . fx@gnu.org)
20170925104459.17798-1-fx@gnu.org
This saves ~1GB.

* gnu/packages/simulation.scm (openfoam)[outputs]: Add debug.
[arguments]: Clean up .o and src after build.
---
gnu/packages/simulation.scm | 13 +++++++++++++
1 file changed, 13 insertions(+)

Toggle diff (33 lines)
diff --git a/gnu/packages/simulation.scm b/gnu/packages/simulation.scm
index de07b6844..fef80a1ac 100644
--- a/gnu/packages/simulation.scm
+++ b/gnu/packages/simulation.scm
@@ -84,6 +84,10 @@
`(("gzip" ,gzip)
("gnuplot" ,gnuplot)
("openmpi" ,openmpi)))
+ ;; FIXME: Also separate tutorials (80MB) and src (60MB); maybe also doc
+ ;; (8MB)
+ (outputs '("debug" ;~60MB
+ "out"))
(arguments
`( ;; Executable files and shared libraries are located in the 'platforms'
;; subdirectory.
@@ -171,6 +175,15 @@
(("lockDir=.*$")
"lockDir=$HOME/.$WM_PROJECT/.wmake\n"))
#t))
+ (add-after 'build 'cleanup
+ ;; Avoid lots of junk installed
+ (lambda _
+ (delete-file-recursively
+ "platforms/linux64GccDPInt32Opt/src")
+ (delete-file-recursively
+ "platforms/linux64GccDPInt32OptSYSTEMOPENMPI/src")
+ (zero?
+ (system* "find" "-name" "*.o" "-delete"))))
(replace 'install
(lambda _
;; use 'OpenFOAM-version' convention
--
2.11.0
L
L
Ludovic Courtès wrote on 25 Sep 2017 14:52
(name . Dave Love)(address . fx@gnu.org)
87fubbj5yr.fsf@gnu.org
Hi Dave,

Dave Love <fx@gnu.org> skribis:

Toggle quote (5 lines)
> This saves ~1GB.
>
> * gnu/packages/simulation.scm (openfoam)[outputs]: Add debug.
> [arguments]: Clean up .o and src after build.

[...]

Toggle quote (16 lines)
> gnu/packages/simulation.scm | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/gnu/packages/simulation.scm b/gnu/packages/simulation.scm
> index de07b6844..fef80a1ac 100644
> --- a/gnu/packages/simulation.scm
> +++ b/gnu/packages/simulation.scm
> @@ -84,6 +84,10 @@
> `(("gzip" ,gzip)
> ("gnuplot" ,gnuplot)
> ("openmpi" ,openmpi)))
> + ;; FIXME: Also separate tutorials (80MB) and src (60MB); maybe also doc
> + ;; (8MB)
> + (outputs '("debug" ;~60MB
> + "out"))

Normally the ‘strip’ phase would strip things. I guess the problem here
is that libraries are not in lib/, so nothing gets stripped. This would
be worked around by simply passing something like:

#:strip-directories '("OpenFOAM-1.2.3/lib")

Toggle quote (10 lines)
> + (add-after 'build 'cleanup
> + ;; Avoid lots of junk installed
> + (lambda _
> + (delete-file-recursively
> + "platforms/linux64GccDPInt32Opt/src")
> + (delete-file-recursively
> + "platforms/linux64GccDPInt32OptSYSTEMOPENMPI/src")
> + (zero?
> + (system* "find" "-name" "*.o" "-delete"))))

Rather:

(for-each delete-file (find-files "." "\\.o$"))

Paul can you confirm that this is OK?

If it is, could you update the patch accordingly, Dave?

Thanks,
Ludo’.
P
P
Paul Garlick wrote on 26 Sep 2017 13:40
(address . 28593@debbugs.gnu.org)
1506426036.2423.32.camel@tourbillion-technology.com
Hi Dave and Ludo,

Thank you Dave for your helpful suggestions on the OpenFOAM package
definition.

Firstly, on the question of adding a debug output, I have checked the
effect of the current '#:strip-directories' keyword definition.  In the
build log:

stripping binaries in "/gnu/store/4zqn4w0wlq0irdwh3dhrdbsr7i3f1dag-
openfoam-4.1/lib/OpenFOAM-4.1/platforms/linux64GccDPInt32Opt/bin" with
"strip" and flags ("--strip-debug" "--enable-deterministic-archives")
stripping binaries in "/gnu/store/4zqn4w0wlq0irdwh3dhrdbsr7i3f1dag-
openfoam-4.1/lib/OpenFOAM-4.1/platforms/linux64GccDPInt32Opt/lib" with
"strip" and flags ("--strip-debug" "--enable-deterministic-archives")

This suggests that the binaries in .../bin and .../lib are being
stripped.  However, if I check a randomly-selected executable in the
bin directory:

$ objdump --syms /home/paul/.guix-profile/lib/OpenFOAM-
4.1/platforms/linux64GccDPInt32Opt/bin/blockMesh | grep debug

0000000000000000       O *UND* 0000000000000000              _ZN
4Foam8fileName5debugE
0000000000000000       O *UND* 0000000000000000              _ZN
4Foam4word5debugE

The 'file' command also reports that the executables and shared objects
are 'not stripped'.  Does adding a debug output achieve the effect of
stripping the binaries? 

Toggle quote (9 lines)
>
> Normally the ‘strip’ phase would strip things.  I guess the problem
> here
> is that libraries are not in lib/, so nothing gets stripped.  This
> would
> be worked around by simply passing something like:
>
>   #:strip-directories '("OpenFOAM-1.2.3/lib")

Would that not give a 'directory not found' message?  Currently,

#:strip-directories (list (string-append
                                  "lib/OpenFOAM-" ,version
                                  "/platforms/linux64GccDPInt32Opt/bin"
)
                                 (string-append
                                  "lib/OpenFOAM-" ,version
                                  "/platforms/linux64GccDPInt32Opt/lib"
))

Toggle quote (18 lines)
> >
> > +                  (add-after 'build 'cleanup
> > +                    ;; Avoid lots of junk installed
> > +                    (lambda _
> > +                      (delete-file-recursively
> > +                       "platforms/linux64GccDPInt32Opt/src")
> > +                      (delete-file-recursively
> > +                       "platforms/linux64GccDPInt32OptSYSTEMOPENMP
> > I/src")
> > +                      (zero?
> > +                       (system* "find" "-name" "*.o" "-delete"))))
> Rather:
>
>   (for-each delete-file (find-files "." "\\.o$"))
>
> Paul can you confirm that this is OK?
>

Maybe.  We need to be careful that we not delete files which are needed
later on.  Typically, a user will copy part of the directory structure
to a subdirectory of $HOME and compile a new solver.  The OpenFOAM
'wmake' utility takes care of the dependencies and re-compiles object
files as needed.  

So, object files under 'platforms/linux64GccDPInt32Opt/src' should be
safe to delete.  However, this needs to be checked to make sure no
dependencies are deleted that cannot easily be re-compiled.  Have you
already checked this Dave by, for example, re-compiling a standard
solver?

Paul.
L
L
Ludovic Courtès wrote on 26 Sep 2017 14:08
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)
873779hdci.fsf@gnu.org
Hi Paul,
Paul Garlick <pgarlick@tourbillion-technology.com> skribis:
Toggle quote (2 lines)
> The 'file' command also reports that the executables and shared objects
> are 'not stripped'.
That’s because we use ‘--strip-debug’ and not ‘--strip-all’ (in some
cases, the latter breaks binaries in weird ways, hence the conservative
choice.)
However, you can see in the list of ELF sections reported by “objdump
-x” that there’s no .debug* section—i.e., binaries contain the symbol
table, but not DWARF debugging info, which is far larger.
Toggle quote (2 lines)
>  Does adding a debug output achieve the effect of stripping the
> binaries? 
I don’t think it makes any difference.
Toggle quote (18 lines)
>> Normally the ‘strip’ phase would strip things.  I guess the problem
>> here
>> is that libraries are not in lib/, so nothing gets stripped.  This
>> would
>> be worked around by simply passing something like:
>>
>>   #:strip-directories '("OpenFOAM-1.2.3/lib")
>
> Would that not give a 'directory not found' message?  Currently,
>
> #:strip-directories (list (string-append
>                                   "lib/OpenFOAM-" ,version
>                                   "/platforms/linux64GccDPInt32Opt/bin"
> )
>                                  (string-append
>                                   "lib/OpenFOAM-" ,version
>                                   "/platforms/linux64GccDPInt32Opt/lib"
> ))
Oh sorry, I had forgotten we already had this. This is perfect!
Toggle quote (18 lines)
>> Rather:
>>
>>   (for-each delete-file (find-files "." "\\.o$"))
>>
>> Paul can you confirm that this is OK?
>>
>
> Maybe.  We need to be careful that we not delete files which are needed
> later on.  Typically, a user will copy part of the directory structure
> to a subdirectory of $HOME and compile a new solver.  The OpenFOAM
> 'wmake' utility takes care of the dependencies and re-compiles object
> files as needed.  
>
> So, object files under 'platforms/linux64GccDPInt32Opt/src' should be
> safe to delete.  However, this needs to be checked to make sure no
> dependencies are deleted that cannot easily be re-compiled.  Have you
> already checked this Dave by, for example, re-compiling a standard
> solver?
I let Dave answer on this part.
Thanks,
Ludo’.
D
D
Dave Love wrote on 27 Sep 2017 23:25
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)
87ing3sukx.fsf@albion.it.manchester.ac.uk
Paul Garlick <pgarlick@tourbillion-technology.com> writes:

Toggle quote (16 lines)
> This suggests that the binaries in .../bin and .../lib are being
> stripped.  However, if I check a randomly-selected executable in the
> bin directory:
>
> $ objdump --syms /home/paul/.guix-profile/lib/OpenFOAM-
> 4.1/platforms/linux64GccDPInt32Opt/bin/blockMesh | grep debug
>
> 0000000000000000       O *UND* 0000000000000000              _ZN
> 4Foam8fileName5debugE
> 0000000000000000       O *UND* 0000000000000000              _ZN
> 4Foam4word5debugE
>
> The 'file' command also reports that the executables and shared objects
> are 'not stripped'.  Does adding a debug output achieve the effect of
> stripping the binaries? 

That was confusing me too, and I was going to ask about it...

Toggle quote (6 lines)
>> > +                      (zero?
>> > +                       (system* "find" "-name" "*.o" "-delete"))))
>> Rather:
>>
>>   (for-each delete-file (find-files "." "\\.o$"))

I don't understand the need to avoid system(*), but I assumed the
optimizations in find make it significantly faster then find-files -- is
that not true? (Dealing with the file structure in openfoam is horribly
slow when I've done builds on the NFS filesystems.)

Toggle quote (14 lines)
> Maybe.  We need to be careful that we not delete files which are needed
> later on.  Typically, a user will copy part of the directory structure
> to a subdirectory of $HOME and compile a new solver.  The OpenFOAM
> 'wmake' utility takes care of the dependencies and re-compiles object
> files as needed.  
>
> So, object files under 'platforms/linux64GccDPInt32Opt/src' should be
> safe to delete.  However, this needs to be checked to make sure no
> dependencies are deleted that cannot easily be re-compiled.  Have you
> already checked this Dave by, for example, re-compiling a standard
> solver?
>
> Paul.

Not in this case, but people have been using my rpm version in anger,
though it's an earlier version. (I was looking at this partly to help
updating the rpm.) I'd have expected to have to regenerate the
dependency files when modifying the source.

[I wish openfoam had a sane build system, even one that stopped on an
error, sigh. Actually, it might be worth patching that, like the rpm --
I've several times missed components not being built -- assuming that
hasn't changed.]
D
D
Dave Love wrote on 27 Sep 2017 23:30
(name . Ludovic Courtès)(address . ludo@gnu.org)
87efqrsubj.fsf@albion.it.manchester.ac.uk
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (4 lines)
> That’s because we use ‘--strip-debug’ and not ‘--strip-all’ (in some
> cases, the latter breaks binaries in weird ways, hence the conservative
> choice.)

Is that something Guix-specific? As far as I know, with rpm and dpkg,
the binaries are always stripped, and I'm not aware of any problem with
that.

Toggle quote (5 lines)
>>  Does adding a debug output achieve the effect of stripping the
>> binaries? 
>
> I don’t think it makes any difference.

Right.

Incidentally, you could save about half the size of the boost
contribution to closures like this by separating the headers and the
libraries, but there was some problem I don;t remember when I tried.
L
L
Ludovic Courtès wrote on 28 Sep 2017 10:36
(name . Dave Love)(address . fx@gnu.org)
87lgkzz0bb.fsf@gnu.org
Dave Love <fx@gnu.org> skribis:

Toggle quote (10 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> That’s because we use ‘--strip-debug’ and not ‘--strip-all’ (in some
>> cases, the latter breaks binaries in weird ways, hence the conservative
>> choice.)
>
> Is that something Guix-specific? As far as I know, with rpm and dpkg,
> the binaries are always stripped, and I'm not aware of any problem with
> that.

I’m pretty sure I tried to default to “--strip-all” instead of
“--strip-debug” and that some packages had problems with that, I forgot
what it was.

Perhaps we should try to revisit this.

Toggle quote (11 lines)
>>>  Does adding a debug output achieve the effect of stripping the
>>> binaries? 
>>
>> I don’t think it makes any difference.
>
> Right.
>
> Incidentally, you could save about half the size of the boost
> contribution to closures like this by separating the headers and the
> libraries, but there was some problem I don;t remember when I tried.

Too bad you don’t remember, it would be worth looking into that.

Ludo’.
D
D
Dave Love wrote on 2 Oct 2017 22:41
(name . Ludovic Courtès)(address . ludo@gnu.org)
87fub1ffjc.fsf@albion.it.manchester.ac.uk
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (18 lines)
> Dave Love <fx@gnu.org> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> That’s because we use ‘--strip-debug’ and not ‘--strip-all’ (in some
>>> cases, the latter breaks binaries in weird ways, hence the conservative
>>> choice.)
>>
>> Is that something Guix-specific? As far as I know, with rpm and dpkg,
>> the binaries are always stripped, and I'm not aware of any problem with
>> that.
>
> I’m pretty sure I tried to default to “--strip-all” instead of
> “--strip-debug” and that some packages had problems with that, I forgot
> what it was.
>
> Perhaps we should try to revisit this.

It seems worth trying.

By the way, I originally thought that debug info was left in the
binaries and a debug package separated it. I think it's unfortunate not
to have debug info available (the GNU build default). It presumably
should be available for something like openfoam, for people to build
parts of, anyhow.

Toggle quote (8 lines)
>> Incidentally, you could save about half the size of the boost
>> contribution to closures like this by separating the headers and the
>> libraries, but there was some problem I don;t remember when I tried.
>
> Too bad you don’t remember, it would be worth looking into that.
>
> Ludo’.

It's easy (but not fast) to try again.
L
L
Ludovic Courtès wrote on 3 Oct 2017 14:33
(name . Dave Love)(address . fx@gnu.org)
87shf08l70.fsf@gnu.org
Dave Love <fx@gnu.org> skribis:

Toggle quote (22 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Dave Love <fx@gnu.org> skribis:
>>
>>> Ludovic Courtès <ludo@gnu.org> writes:
>>>
>>>> That’s because we use ‘--strip-debug’ and not ‘--strip-all’ (in some
>>>> cases, the latter breaks binaries in weird ways, hence the conservative
>>>> choice.)
>>>
>>> Is that something Guix-specific? As far as I know, with rpm and dpkg,
>>> the binaries are always stripped, and I'm not aware of any problem with
>>> that.
>>
>> I’m pretty sure I tried to default to “--strip-all” instead of
>> “--strip-debug” and that some packages had problems with that, I forgot
>> what it was.
>>
>> Perhaps we should try to revisit this.
>
> It seems worth trying.

I take it that you’re volunteering? :-)

The change is a simple one-liner, but making sure that nothing breaks of
course takes more time (mostly CPU time!).

Toggle quote (6 lines)
> By the way, I originally thought that debug info was left in the
> binaries and a debug package separated it. I think it's unfortunate not
> to have debug info available (the GNU build default). It presumably
> should be available for something like openfoam, for people to build
> parts of, anyhow.

Quoth

The ‘debug’ output mechanism in Guix is implemented by the
‘gnu-build-system’ (*note Build Systems::). Currently, it is
opt-in—debugging information is available only for the packages with
definitions explicitly declaring a ‘debug’ output. This may be changed
to opt-out in the future if our build farm servers can handle the load.
To check whether a package has a ‘debug’ output, use ‘guix package
--list-available’ (*note Invoking guix package::).

It’s mostly a matter of disk space and bandwidth.

Ludo’.
L
L
Ludovic Courtès wrote on 7 Oct 2017 22:45
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)
87o9piit59.fsf@gnu.org
Hi,

ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (2 lines)
> Paul Garlick <pgarlick@tourbillion-technology.com> skribis:

[...]

Toggle quote (21 lines)
>>> Rather:
>>>
>>>   (for-each delete-file (find-files "." "\\.o$"))
>>>
>>> Paul can you confirm that this is OK?
>>>
>>
>> Maybe.  We need to be careful that we not delete files which are needed
>> later on.  Typically, a user will copy part of the directory structure
>> to a subdirectory of $HOME and compile a new solver.  The OpenFOAM
>> 'wmake' utility takes care of the dependencies and re-compiles object
>> files as needed.  
>>
>> So, object files under 'platforms/linux64GccDPInt32Opt/src' should be
>> safe to delete.  However, this needs to be checked to make sure no
>> dependencies are deleted that cannot easily be re-compiled.  Have you
>> already checked this Dave by, for example, re-compiling a standard
>> solver?
>
> I let Dave answer on this part.

I think we got sidetracked by the discussion about debugging info.

Paul, Dave: what do we do this patch?


TIA,
Ludo’.
P
P
Paul Garlick wrote on 9 Oct 2017 13:06
(name . Ludovic Courtès)(address . ludo@gnu.org)
1507547167.17241.18.camel@tourbillion-technology.com
Hi Ludo and Dave,

Toggle quote (5 lines)
> Paul, Dave: what do we do this patch?
>
>   https://bugs.gnu.org/28593
>

To recap on my comments on the patch:

i) a debug output would be fine; possibly with an extra comment for
OpenFOAM users to say what it can be used for

ii) deleting object files, to save disk space, under
'platforms/linux64GccDPInt32Opt/src' should also be fine, with the
proviso that the re-compilation process should be checked before
committing.  There is an example procedure, albeit for an earlier
ture_to_icoFoam .  A slightly modified procedure should work for
version 4.1.

Dave, can you try this on your patched version?  'wmake' should re-
generate the object files that are needed and produce a new executable.
 Check that there are no instances of errors such as 'file not found'

iii) substitute a more descriptive word than 'junk' for the object
files; 'intermediate' or some such

iv) the source files take up much less space than the object files.  I
wouldn't worry about deleting them.

Best regards,

Paul.
D
D
Dave Love wrote on 19 Oct 2017 13:06
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)
87o9p3mm73.fsf@albion.it.manchester.ac.uk
Paul Garlick <pgarlick@tourbillion-technology.com> writes:

Toggle quote (12 lines)
> ii) deleting object files, to save disk space, under
> 'platforms/linux64GccDPInt32Opt/src' should also be fine, with the
> proviso that the re-compilation process should be checked before
> committing.  There is an example procedure, albeit for an earlier
> version, given at https://openfoamwiki.net/index.php/How_to_add_tempera
> ture_to_icoFoam .  A slightly modified procedure should work for
> version 4.1.
>
> Dave, can you try this on your patched version?  'wmake' should re-
> generate the object files that are needed and produce a new executable.
>  Check that there are no instances of errors such as 'file not found'

Sorry, I haven't had a chance to check that yet, and I'm hampered
working on openfoam by a small-ish laptop with a slow disk. I didn't
expect the dependency files to be necessary, as they aren't shipped in
my rpms for previous versions that people have been using, but I will do
the experiment when I can.
L
L
Ludovic Courtès wrote on 19 Oct 2017 14:15
(name . Dave Love)(address . fx@gnu.org)
87d15jjpuc.fsf@gnu.org
Hello,

Dave Love <fx@gnu.org> skribis:

Toggle quote (20 lines)
> Paul Garlick <pgarlick@tourbillion-technology.com> writes:
>
>> ii) deleting object files, to save disk space, under
>> 'platforms/linux64GccDPInt32Opt/src' should also be fine, with the
>> proviso that the re-compilation process should be checked before
>> committing.  There is an example procedure, albeit for an earlier
>> version, given at https://openfoamwiki.net/index.php/How_to_add_tempera
>> ture_to_icoFoam .  A slightly modified procedure should work for
>> version 4.1.
>>
>> Dave, can you try this on your patched version?  'wmake' should re-
>> generate the object files that are needed and produce a new executable.
>>  Check that there are no instances of errors such as 'file not found'
>
> Sorry, I haven't had a chance to check that yet, and I'm hampered
> working on openfoam by a small-ish laptop with a slow disk. I didn't
> expect the dependency files to be necessary, as they aren't shipped in
> my rpms for previous versions that people have been using, but I will do
> the experiment when I can.

Paul seems to have access to a biffy build machine ;-), so maybe you can
update/adjust the patch, Paul?

Ludo’.
P
P
Paul Garlick wrote on 20 Oct 2017 12:32
(address . 28593@debbugs.gnu.org)
1508495524.2713.20.camel@tourbillion-technology.com
Hi Dave and Ludo,

Toggle quote (9 lines)
> > Sorry, I haven't had a chance to check that yet, and I'm hampered
> > working on openfoam by a small-ish laptop with a slow disk.  I
> > didn't
> > expect the dependency files to be necessary, as they aren't shipped
> > in
> > my rpms for previous versions that people have been using, but I
> > will do
> > the experiment when I can.

Great, thanks.  

One of the nice features of OpenFOAM is that the principles of
operation on laptops is just the same as that on supercomputers.

Toggle quote (4 lines)
> Paul seems to have access to a biffy build machine ;-), so maybe you
> can
> update/adjust the patch, Paul?

Well, based on feedback on the existing package definition, I am
starting to think about how best to deal with multiple versions and
simplify the patch step.  There is a new version (5.0) that has been
released that I can work on.  

It is likely to take some time, although it should be quicker to
develop than the original definition.  So, if Dave can take charge of
this finishing patch (#28593) that would work best for me.

In the meantime, I have made an announcement of the package
availability on the CFD Online discusssion forum.  The link is:

865-openfoam-4-1-packaged-gnu-guix.html

Best regards,

Paul.
L
L
Ludovic Courtès wrote on 20 Oct 2017 13:28
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)
87y3o6vz0t.fsf@gnu.org
Hi Paul,

Paul Garlick <pgarlick@tourbillion-technology.com> skribis:

[...]

Toggle quote (13 lines)
>> Paul seems to have access to a biffy build machine ;-), so maybe you
>> can
>> update/adjust the patch, Paul?
>
> Well, based on feedback on the existing package definition, I am
> starting to think about how best to deal with multiple versions and
> simplify the patch step.  There is a new version (5.0) that has been
> released that I can work on.  
>
> It is likely to take some time, although it should be quicker to
> develop than the original definition.  So, if Dave can take charge of
> this finishing patch (#28593) that would work best for me.

Sounds like a plan.

Toggle quote (5 lines)
> In the meantime, I have made an announcement of the package
> availability on the CFD Online discusssion forum.  The link is:
>
> https://www.cfd-online.com/Forums/openfoam-news-announcements-other/193865-openfoam-4-1-packaged-gnu-guix.html

Nice!

It will be interesting to see to what extent it helps OpenFOAM users and
developers address their deployment issues.

Cheers,
Ludo’.
D
D
Dave Love wrote on 20 Oct 2017 17:26
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)
877evplu26.fsf@albion.it.manchester.ac.uk
Paul Garlick <pgarlick@tourbillion-technology.com> writes:

Toggle quote (3 lines)
> One of the nice features of OpenFOAM is that the principles of
> operation on laptops is just the same as that on supercomputers.

(Modulo MPI) but it's bad enough working with it on a decent login node!
D
D
Dave Love wrote on 20 Oct 2017 17:28
(name . Ludovic Courtès)(address . ludo@gnu.org)
8760b9lty6.fsf@albion.it.manchester.ac.uk
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (7 lines)
>
> Nice!
>
> It will be interesting to see to what extent it helps OpenFOAM users and
> developers address their deployment issues.

In my experience of offering rpms and build advice, in the UK they're
remarkably resistant to making life easy, or at least their support
people are. Actually, that's not unique to OF; sigh.
D
D
Dave Love wrote on 22 Oct 2017 18:15
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)
874lqrjh0y.fsf@albion.it.manchester.ac.uk
Paul Garlick <pgarlick@tourbillion-technology.com> writes:

Toggle quote (12 lines)
> ii) deleting object files, to save disk space, under
> 'platforms/linux64GccDPInt32Opt/src' should also be fine, with the
> proviso that the re-compilation process should be checked before
> committing.  There is an example procedure, albeit for an earlier
> version, given at https://openfoamwiki.net/index.php/How_to_add_tempera
> ture_to_icoFoam .  A slightly modified procedure should work for
> version 4.1.
>
> Dave, can you try this on your patched version?  'wmake' should re-
> generate the object files that are needed and produce a new executable.
>  Check that there are no instances of errors such as 'file not found'

I successfully rebuilt pisoFoam following the example in the current
documentation. Is that good enough?

Here's a modified patch to change the comment and avoid an empty
directory.
From dc88db3e91c70da5e6e557ed5fdd528499cb1c65 Mon Sep 17 00:00:00 2001
From: Dave Love <fx@gnu.org>
Date: Sat, 21 Oct 2017 17:20:42 +0100
Subject: [PATCH] gnu: openfoam: Clean up to reduce closure.

This saves ~1GB.

* gnu/packages/simulation.scm (openfoam)[outputs]: Add debug.
[arguments]: Clean up .o and src after build.
---
gnu/packages/simulation.scm | 13 +++++++++++++
1 file changed, 13 insertions(+)

Toggle diff (33 lines)
diff --git a/gnu/packages/simulation.scm b/gnu/packages/simulation.scm
index de07b6844..3e65d1687 100644
--- a/gnu/packages/simulation.scm
+++ b/gnu/packages/simulation.scm
@@ -84,6 +84,10 @@
`(("gzip" ,gzip)
("gnuplot" ,gnuplot)
("openmpi" ,openmpi)))
+ ;; FIXME: Also separate tutorials (80MB) and src (60MB); maybe also doc
+ ;; (8MB)
+ (outputs '("debug" ;~60MB
+ "out"))
(arguments
`( ;; Executable files and shared libraries are located in the 'platforms'
;; subdirectory.
@@ -171,6 +175,15 @@
(("lockDir=.*$")
"lockDir=$HOME/.$WM_PROJECT/.wmake\n"))
#t))
+ (add-after 'build 'cleanup
+ ;; Avoid unncessary, voluminous object and dep files
+ (lambda _
+ (delete-file-recursively
+ "platforms/linux64GccDPInt32Opt/src")
+ (delete-file-recursively
+ "platforms/linux64GccDPInt32OptSYSTEMOPENMPI")
+ (zero?
+ (system* "find" "-name" "*.o" "-delete"))))
(replace 'install
(lambda _
;; use 'OpenFOAM-version' convention
--
2.11.0
P
P
Paul Garlick wrote on 23 Oct 2017 17:00
(name . Dave Love)(address . fx@gnu.org)
1508770811.11712.19.camel@tourbillion-technology.com
On Sun, 2017-10-22 at 17:15 +0100, Dave Love wrote:
Toggle quote (5 lines)
>
> I successfully rebuilt pisoFoam following the example in the current
> documentation.  Is that good enough?


Yes, that is a good example case.  Thank you for doing the check.


Toggle quote (3 lines)
> Here's a modified patch to change the comment and avoid an empty
> directory.

Fine, with a caveat on the FIXME comment:

i) 'wmake' will fail to find headers in subdirectories of 'src' if they
are not installed.  So, a re-compilation as you did above would not be
possible without installing the extra output.  This is perhaps
confusing for a new user, who may not know the details of the
dependency structure.

ii) OpenFOAM would be difficult to use without the 'tutorials'
directory, as these are often used as the starting point for new
development.  I think it is helpful for these files to be installed by
default.

My own preference would be to not fix the FIXME (or, in fact, to omit
the comment at this stage).

Best,

Paul.
L
L
Ludovic Courtès wrote on 1 Dec 2017 11:27
(name . Dave Love)(address . fx@gnu.org)
87374uivyq.fsf@gnu.org
Dave Love <fx@gnu.org> skribis:

Toggle quote (10 lines)
>>From dc88db3e91c70da5e6e557ed5fdd528499cb1c65 Mon Sep 17 00:00:00 2001
> From: Dave Love <fx@gnu.org>
> Date: Sat, 21 Oct 2017 17:20:42 +0100
> Subject: [PATCH] gnu: openfoam: Clean up to reduce closure.
>
> This saves ~1GB.
>
> * gnu/packages/simulation.scm (openfoam)[outputs]: Add debug.
> [arguments]: Clean up .o and src after build.

I removed the FIXME as suggested by Paul, made the changes below, and
committed.

Thank you,
Ludo’.
Toggle diff (31 lines)
diff --git a/gnu/packages/simulation.scm b/gnu/packages/simulation.scm
index 3e65d1687..a5b661e34 100644
--- a/gnu/packages/simulation.scm
+++ b/gnu/packages/simulation.scm
@@ -84,8 +84,6 @@
`(("gzip" ,gzip)
("gnuplot" ,gnuplot)
("openmpi" ,openmpi)))
- ;; FIXME: Also separate tutorials (80MB) and src (60MB); maybe also doc
- ;; (8MB)
(outputs '("debug" ;~60MB
"out"))
(arguments
@@ -176,14 +174,14 @@
"lockDir=$HOME/.$WM_PROJECT/.wmake\n"))
#t))
(add-after 'build 'cleanup
- ;; Avoid unncessary, voluminous object and dep files
+ ;; Avoid unncessary, voluminous object and dep files.
(lambda _
(delete-file-recursively
"platforms/linux64GccDPInt32Opt/src")
(delete-file-recursively
"platforms/linux64GccDPInt32OptSYSTEMOPENMPI")
- (zero?
- (system* "find" "-name" "*.o" "-delete"))))
+ (for-each delete-file (find-files "." "\\.o$"))
+ #t))
(replace 'install
(lambda _
;; use 'OpenFOAM-version' convention
Closed
?