View Issue Details

IDProjectCategoryView StatusLast Update
0000609OpenFOAM[All Projects] Bugpublic2015-01-01 14:41
Reporteruser486Assigned Tohenry 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
PlatformLinuxOSUbuntuOS Version10.04
Product Version 
Fixed in Version 
Summary0000609: ubuntu installation process could make use of /etc/profile.d instead of ~/.bashrc
DescriptionIt is my understanding that the installation process on Ubuntu machines could be streamlined by dropping some files into /etc/profile.d on Ubuntu. I believe this would enable environment variables to be added to the user's environment automatically (for all users), and so would eliminate the need for manual steps after installation has completed.
TagsNo tags attached.

Activities

user19

2012-08-01 08:30

  ~0001519

Except that this might not be desirable at all, because OpenFOAM sets so many environment variables and defines a boatload of aliases. What could be installed, though, is a file in /etc/profile.d which defines an alias that does the sourcing, e.g. called "initfoam" or some such.

user486

2012-08-01 09:39

  ~0001521

Last edited: 2012-08-01 09:40

View 2 revisions

Perhaps it would be easiest to rewrite the wrapper scripts (blockMesh, icoFoam, paraFoam et al) that load the environment variables from ~/.openfoamrc, with a fallback to /etc/openfoamrc, so that the environment variables are only set in the context of the openfoam executables, and not all the time? (It would be even be possible to do this in a way that was backward compatible, by first checking for the environment variables and not loading them if they are already set?)

Are the cases where environment variables need to change during the course of a simulation, or in-between the different steps of meshing, solving, viewing?

wyldckat

2012-08-01 09:48

updater   ~0001523

There are over 300 applications and scripts in OpenFOAM, all of which only need the working environment during their execution.

Side note: do not forget that some people need to have more than one version of OpenFOAM installed in their machines!

user486

2012-08-01 09:59

  ~0001524

Every script (at least every shell script) could easily be prefixed with a single line that would act to load the environment from an rc file iff missing. Even for scripts-called-from-within-scripts, I think this option would be safe.

For users with multiple versions of OpenFOAM, two solutions:
1. if using multiple versions, but only one at a time, just make changes to ~/.openfoamrc (copy files in and out, or comment/uncomment lines, perhaps)
2. if using multiple versions simultaneously, revert to the use of environment variables, which would still be allowed; the rc files would only be accessed if the env vars were missing.

wyldckat

2012-08-01 10:55

updater   ~0001525

FYI: this has already been partially discussed here: http://www.openfoam.org/mantisbt/view.php?id=256


The current "somewhat popular" solution has been to resort to aliases - example:
  alias of171='source /opt/openfoam171/etc/bashrc'
  alias of211='source /opt/openfoam211/etc/bashrc'

OpenFOAM also provides direct initializations; e.g.:
  alias of211-32bit='source /opt/openfoam211/etc/bashrc WM_ARCH_OPTION=32'

As for the DEB package to create a script, e.g. "/etc/profile.d/openfoam211.sh", it could have the alias for each installed version. The downside is that the user would have to start a new terminal for things to work properly...

user19

2012-08-01 11:29

  ~0001526

Last edited: 2012-08-01 11:31

View 2 revisions

What I do on my local installations is to use environment modules (http://modules.sourceforge.net) instead of the bashrc and cshrc scripts. OpenCFD could ship the environment modules package directly in the ThirdParty distribution (it would add a dependency on a TCL interpreter, though), and then instead of providing the bashrc and cshrc script, include module files.

One big advantage would be that you need only a single environment module which works for all popular shells, not two. The other pro is that you can "remove" the module from your environment, i.e. clean the shell up. Similarly, you can switch between multiple versions of the same module.

Issue History

Date Modified Username Field Change
2012-08-01 01:22 user486 New Issue
2012-08-01 08:30 user19 Note Added: 0001519
2012-08-01 09:39 user486 Note Added: 0001521
2012-08-01 09:40 user486 Note Edited: 0001521 View Revisions
2012-08-01 09:48 wyldckat Note Added: 0001523
2012-08-01 09:59 user486 Note Added: 0001524
2012-08-01 10:55 wyldckat Note Added: 0001525
2012-08-01 11:29 user19 Note Added: 0001526
2012-08-01 11:31 user19 Note Edited: 0001526 View Revisions
2015-01-01 14:40 henry Status new => closed
2015-01-01 14:41 henry Assigned To => henry
2015-01-01 14:41 henry Resolution open => no change required