Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a "--fast" flag to update_and_rebuild_libmesh.sh? #6741

Closed
jwpeterson opened this issue Apr 12, 2016 · 10 comments
Closed

Add a "--fast" flag to update_and_rebuild_libmesh.sh? #6741

jwpeterson opened this issue Apr 12, 2016 · 10 comments
Labels
C: MOOSE Scripts P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.

Comments

@jwpeterson
Copy link
Member

Description of the enhancement or error report

We run rm -rf build every time someone runs the update_and_rebuild_libmesh.sh script. This, combined with the fact that we always build three methods (opt, dbg, oprof), makes libmesh updates very painful for users. We should be able to get away with just rebuilding libmesh (without cleaning) after the submodule update. We could do this by default or add a flag that conditionally enables it.

Rationale for the enhancement or information for reproducing the error

To reproduce: just run update_and_rebuild_libmesh.sh on a 2 or 4-core computer...and wait.

Identified impact

This will impact almost everyone who uses MOOSE, by speeding up their libmesh update times.

@YaqiWang
Copy link
Contributor

How about add another one --skip-submodule-update? Users might checked out libmesh on their own.

@jwpeterson
Copy link
Member Author

I don't understand... If you maintain your own libmesh outside the submodule in MOOSE, then you aren't running this script. It is hardcoded to cd $SCRIPT_DIR/../libmesh and build there.

@YaqiWang
Copy link
Contributor

libMesh is still under moose/libmesh, just checked out manually. That is what I did. moose/libmesh to me a convenient place.

@jwpeterson
Copy link
Member Author

Wow, OK, that is a really special and confusing case. Doesn't your git status always show a modification to the libmesh submodule which you have to ignore? I think it's fine if you want to work like this, but we definitely don't want to encourage others to do this...

@YaqiWang
Copy link
Contributor

Yes, git status shows that libmesh is modified. Then if you run the script again, it will wipe out your checkout and update libmesh to the hash maintained by moose.

@bwspenc
Copy link
Contributor

bwspenc commented Apr 13, 2016

I like this idea. While you're at it, are you planning to have it just build opt? That would help ease the pain of the build on the clusters when we get rid of the prebuilt libmesh since most of the time when people are building on the cluster, I'd guess that they just want opt.

@friedmud
Copy link
Contributor

I don't mind the idea, but I doubt it will save people much time. When we do libMesh updates surely a critical header or two have changed in the intervening time that will cause a whole library rebuild no matter what.

@bwspenc the script honors the METHODS environment variable, right?

@permcody
Copy link
Member

While you're at it, could you add a --fast flag to MOOSE too? I'd like it
to run faster when I use that flag.

On Wed, Apr 13, 2016 at 9:47 PM Derek Gaston notifications@github.com
wrote:

I don't mind the idea, but I doubt it will save people much time. When we
do libMesh updates surely a critical header or two have changed in the
intervening time that will cause a whole library rebuild no matter what.

@bwspenc https://github.com/bwspenc the script honors the METHODS
environment variable, right?


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#6741 (comment)

@bwspenc
Copy link
Contributor

bwspenc commented Apr 14, 2016

@permcody Yeah, like the 'turbo' button on my computer.

jwpeterson added a commit to jwpeterson/moose that referenced this issue Apr 19, 2016
The --fast flag skips the steps of removing the build directory and
configuring libmesh, so we do not allow other configure flags to be
passed in addition to --fast.  We also check that there is an
pre-existing build directory when the user passes --fast, you can't do
--fast the first time you build libmesh.

Refs idaholab#6741.
jwpeterson added a commit to jwpeterson/moose that referenced this issue Apr 19, 2016
The --fast flag skips the steps of removing the build directory and
configuring libmesh, so we do not allow other configure flags to be
passed in addition to --fast.  We also check that there is a
pre-existing build directory when the user passes --fast, you can't do
--fast the first time you build libmesh.

Refs idaholab#6741.
@permcody permcody added C: MOOSE Scripts T: task An enhancement to the software. P: normal A defect affecting operation with a low possibility of significantly affects. labels Apr 20, 2016
jwpeterson added a commit to jwpeterson/moose that referenced this issue Apr 26, 2016
There are still old packages out there, and people who build their own
PETSc without all the bells and whistles, so this is a no-go.

Refs idaholab#6741, idaholab#6836.
cpgr pushed a commit to cpgr/moose that referenced this issue May 4, 2016
The --fast flag skips the steps of removing the build directory and
configuring libmesh, so we do not allow other configure flags to be
passed in addition to --fast.  We also check that there is a
pre-existing build directory when the user passes --fast, you can't do
--fast the first time you build libmesh.

Refs idaholab#6741.
cpgr pushed a commit to cpgr/moose that referenced this issue May 4, 2016
There are still old packages out there, and people who build their own
PETSc without all the bells and whistles, so this is a no-go.

Refs idaholab#6741, idaholab#6836.
jwpeterson added a commit to jwpeterson/moose that referenced this issue Jun 6, 2016
This will somewhat reduce the amount of recompilation required after
libmesh updates, although the main benefit will be to people who
recompile libmesh more frequently, but do so via the
update_and_rebuild_libmesh.sh script instead of using custom build
scripts.  @dschwen and I confirmed that the -C flag does the right
thing (only copying files which have changed) on both Linux and Mac.

Refs idaholab#6741.
jwpeterson added a commit to jwpeterson/moose that referenced this issue Jun 28, 2016
alcoae pushed a commit to alcoae/moose that referenced this issue Jul 14, 2016
permcody added a commit to permcody/moose that referenced this issue Aug 22, 2016
@milljm
Copy link
Member

milljm commented Nov 18, 2016

@jwpeterson
Came across this old issue... can it be closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: MOOSE Scripts P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.
Projects
None yet
Development

No branches or pull requests

6 participants