Configuration of BUILD_ID

The BUILD_ID is used in the build_tsmp2.sh script to specify the build directory as well as the install directory. As the binaries are stored in the latter, the name has a major impact on the users. The BUILD_ID was introduced in PR #53 and there has already been some discussion in this PR. However, I would like to use this issue to bundle the discussion and lead to a conclusion.

In my opinion, the default ‘BUILD_ID’ should be as minimalistic as possible. Namely, I would suggest the following ID:
<machine/system-identifier>_<model-identifier>

If someone wants to use different environments and also wants to save in different folders, they can also set the BUILD_ID manually.

What are your opinions about this?

I'm okay with this.

I'm also okay with leaving as is.

I'm all for minimalism, but it has to be the right kind; not the lazy kind, and certainly not the wrong kind. It's good to express BUILD_ID concisely, but not at the expense of its uniqueness. By definition, an identifier (ID) must be unique.

One possible representation of a unique BUILD_ID can be derived from 3 pieces of information: (1) system ID, (2) environment ID, and (3) model ID. Remove any one of those and BUILD_ID becomes non-unique. Environment ID, which encodes information about the compilers used, is missing from the proposed BUILD_ID.

Whilst BUILD_ID can be set manually, I wouldn't rely on users setting it uniquely; they're not even supposed to do so. A non-unique default BUILD_ID could point to an existing build folder set up with a completely different environment, and is likely to end up throwing all sorts of weird errors to users. Enforcing fresh builds can solve this, but this is not necessary. Also, sometimes it can be useful to reuse an existing build folder (see next commment).

We can easily eliminate a huge variety of build errors by simply choosing a default BUILD_ID that is unique. I would satisfy this criterion first before finding a more concise way to express BUILD_ID.

One advantage of a unique default BUILD_ID is it allows resuming builds without troubles. This is handy during development:

TSMP2/build_tsmp2.sh

Lines 256 to 262 in 716db14

    
           read -p "${cmake_build_dir} aleady exists. Do you want to resume existing build? (Y/n) " yn 
        
           if [ "${yn,}" = "n" ];then 
        
             message "Deleting previous build directory..." 
        
             rm -rf ${cmake_build_dir} 
        
           else 
        
             message "Resuming previous build $(basename ${cmake_build_dir}.)" 
        
           fi

If BUILD_ID is unique, any existing ${cmake_build_dir} is guaranteed to be generated from the same environment as the one that has been loaded.

Resuming builds is also possible with a non-unique BUILD_ID, but it would be error-prone and cumbersome, i.e.,

If users want to use different environments and also want to save in different folders, they have to set the BUILD_ID manually.

@s-poll

The BUILD_ID is used in the build_tsmp2.sh script to specify the build directory as well as the install directory. As the binaries are stored in the latter, the name has a major impact on the users.

@s-poll can you give specific examples? Those have to be weighed against the side effects of a non-unique BUILD_ID that I've just described.

@s-poll

By definition, an identifier (ID) must be unique.

In an ideal world, I would wholeheartedly agree with this statement. However, this is absolutely not the case in the current status, and I'm not even sure if this is easily realisable. For example, in the current case, different versions of MPI are not intercepted, or if you load additional modules such as Scalasca.

A non-unique default BUILD_ID could point to an existing build folder set up with a completely different environment, and is likely to end up throwing all sorts of weird errors to users.

One advantage of a unique default BUILD_ID is it allows resuming builds without troubles. This is handy during development:

TSMP2/build_tsmp2.sh

Lines 256 to 262 in 716db14

read -p "${cmake_build_dir} aleady exists. Do you want to resume existing build? (Y/n) " yn

if [ "${yn,}" = "n" ];then

message "Deleting previous build directory..."

rm -rf ${cmake_build_dir}

else

message "Resuming previous build $(basename ${cmake_build_dir}.)"

fi

This code snippet is a very nice example of how it would be more robust to query the environment file instead of the name of the build ID. The environment file is saved with the binaries, so that such an if statement is possible.

@s-poll can you give specific examples? Those have to be weighed against the side effects of a non-unique BUILD_ID that I've just described.

As mentioned above, the current BUILD-ID is also non-unique. As the binaries of the components are saved in these folder names, these folders are accessed during each simulation or at least copied from them beforehand.

Furthermore, with a BUILD-ID with environment information you need prior knowledge of this to access the binaries folder uniquely.

In an ideal world, I would wholeheartedly agree with this statement. However, this is absolutely not the case in the current status, and I'm not even sure if this is easily realisable. For example, in the current case, different versions of MPI are not intercepted, or if you load additional modules such as Scalasca.

Those cases already fall under environment ID. It's true that $STAGES_$COMPILER doesn't encode different MPI versions nor Scalasca. However the solution here is to improve the representation of environment ID, not remove it completely.

with a BUILD-ID with environment information you need prior knowledge of this to access the binaries folder uniquely.

Who needs it? The full path to the installed binaries is stored in ${cmake_install_dir} and passed to cmake as it is supposed to be.

As everything is in environment ID already, I think it is fine to have a shorter BUILD_ID, so ${SYSTEMNAME}_${model_id}.

This, in turn, would be easier to predict in the WFE. It's no good to bother the WFE with the stage or compiler; the WFE is ignorant (and wants to be ignorant) about that. Only model_id is essential in the WFE (and SYSTEMNAME easy to guess).

IMO knowing which environment file was sourced in ./build_tsmp2.sh is a separate issue and one that isn't exclusively solved by setting a WFE-guessable BUILD_ID format. As I've explained on my previous comment, ${SYSTEMNAME}_${model_id} is an obviously broken syntax so I'd push back on this.

How about changing build_tsmp2.sh such that it supports the following workflow?

# Enable build_tsmp2 to work out-of-repo
alias build_tsmp2='/path/to/TSMP2/build_tsmp2.sh'

# Create case
CASE_NAME="EU-CORDEX-12km"
mkdir ${CASE_NAME} && cd ${CASE_NAME}

# Build TSMP2 and generate tsmp2.env in the current directory
build_tsmp2 eCLM ParFlow ICON

# tsmp2.env will contain all the necessary modules to load
# plus environment variables which could be useful for
# sbatch scripts, e.g.
#
# TSMP2_INSTALL_ROOT=/path/to/TSMP2/installation
# PARFLOW_DIR=${TSMP2_INSTALL_ROOT}                   # required by some Parflow TCL scripts
# <model>_EXE=${TSMP2_INSTALL_ROOT}/bin/<model>.exe   # for srun --multi-prog
# etc.

A tsmp2.env file can be generated in the current directory after a successful build. The scope of this env file covers necessary variables for simulation runs and as such could be further tailored by users or integrated into WFE.

At the moment, in the workflow engine, TSMP2 is a submodule and the build process takes place therein. The advantage is that this should provide a complete archive for a model simulation run.

With your proposal, the build is still archived with the simulation, but not the source codes (including the build scripts).

I think this discussion is currently heading in the wrong direction. Instead of simplifying things, the proposal would make it more complicated without creating major grooves.

As I've explained on my previous comment, ${SYSTEMNAME}_${model_id} is an obviously broken syntax so I'd push back on this.

Using the current build-id (${SYSTEMNAME}_${model_id}_${STAGES}_${COMPILER}) is obviously as broken as `${SYSTEMNAME}_${model_id}. Worse still, it combines the disadvantages. It is neither unique and you still need prior knowledge of the environment to access the installation folder.

A tsmp2.env file can be generated in the current directory after a successful build. The scope of this env file covers necessary variables for simulation runs and as such could be further tailored by users or integrated into WFE.

The environment-file is already stored in the installation folder. This also ensures that the correct env is used in the simulations.

We should distinguish between defaults and specific applications. As already written above, IMO the defaults should be as simple as possible, the build_tsmp2.sh could be written to check the environment to avoid environment conflicts. Marco has already pointed out that the build_tsmp2.sh is intentionally ignorant about the environments of the TSMP2 simulation used. If someone wants to use specific settings, e.g. to compare environments, this can be set.

In my view, it seems to boil down to the following. Do we want a unique - and by that I mean really unique - BUILD-ID, which leads to a very long build-id by default, or do we leave it simple? If the term ID is disturbing, we could also rename it BUILD-NAME.

We can discuss this during the SDLTS meeting once Daniel is back. I see the benefits to both naming approaches (also their disadvantages). If we decide to keep the shorter, simpler version, we should consider maintaining an easily accessible record of the long-name build ID. This way, if a user has issues with their build or running the model, we can quickly reference the relevant ID, making our work more efficient.

It also came to my mind that BUILD_ID is not a very good name in case you'd go for a non-unique (simple and easy to find by a script) name.

Really unique would entail, e.g., the environment file path name with the TSMP2 repo's commit hash (which determines the content and the commit hashes of all model components if I understand git submodules well enough).

Half way being sort of unique with BUILD_ID="${SYSTEMNAME^^}_${STAGE}_${compiler^^}_${model_id}" appears to make less and less sense to me.

@s-poll

@s-poll and I had a productive discussion this afternoon regarding this issue.

The misunderstanding springs from the expectations of WFE (Stefan's viewpoint) vs. a pure build process that ignores any external tooling (my argument). Stefan and I have agreed that there has to be a clear separation between the WFE and the TSMP2 build system, which means WFE should avoid relying on the internal workings of build_tsmp2.sh as much as possible. This is what this BUILD_ID issue is all about. On the other hand, the TSMP2 build system has to make a minimal set of guarantees so that WFE and other tools won't break. For example, build outputs must have predictable file structure and filenames.

Back to BUILD_ID: Stefan's idea is to copy the environment file to the build directory so that build_tsmp2.sh can safely reuse the build directory if it contains the same environment file as the one being sourced. This would solve the build environment ambiguity, and hence BUILD_ID doesn't need to be unique anymore and can be reverted to its original format ${SYSTEMNAME}_${model_id}.

@kvrigor

if [ -e "${cmake_tsmp2_dir}/bld/$(basename ${tsmp2_env})" ]; then
    read -p "… already exists.  Do you want to … ?"
    …
fi
…
source "${cmake_tsmp2_dir}/bld/$(basename ${tsmp2_env})"

Then you're sure that your env file is already in the build dir for the build to überhaupt start.
I did not test this or check if you can do it in this order in our build script.
I am not sure if user interaction is needed here (abort, don't overwrite and continue, overwrite and continue) or a check if the env files are the same and/or abort only if they are different...
The path derivation could be prettier.
For the rest I leave @kvrigor (and @s-poll) to work this out (many chefs and such).

Navigation Menu

Repository navigation

Configuration of `BUILD_ID` #66

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	read -p "${cmake_build_dir} aleady exists. Do you want to resume existing build? (Y/n) " yn
	if [ "${yn,}" = "n" ];then
	message "Deleting previous build directory..."
	rm -rf ${cmake_build_dir}
	else
	message "Resuming previous build $(basename ${cmake_build_dir}.)"
	fi

Configuration of BUILD_ID #66

Description

Activity

mvhulten commented on Apr 18, 2025

kvrigor commented on Apr 19, 2025

kvrigor commented on Apr 19, 2025

kvrigor commented on Apr 19, 2025

s-poll commented on Apr 19, 2025

kvrigor commented on Apr 22, 2025

mvhulten commented on Apr 28, 2025

kvrigor commented on Apr 28, 2025

mvhulten commented on Apr 29, 2025

s-poll commented on Apr 29, 2025

AGonzalezNicolas commented on Apr 29, 2025

mvhulten commented on Apr 29, 2025

kvrigor commented on Apr 29, 2025

mvhulten commented on Apr 30, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Configuration of `BUILD_ID` #66