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

Dependency graph instead of tree #6

Open
antoine-morvan opened this issue Dec 8, 2023 · 3 comments
Open

Dependency graph instead of tree #6

antoine-morvan opened this issue Dec 8, 2023 · 3 comments

Comments

@antoine-morvan
Copy link

antoine-morvan commented Dec 8, 2023

Hello,

Currently, it seems to me that the dependencies we can express in the JUBE input can only be a tree. For instance, my input could look like this :

name: testjube
outpath: testjube_bench
comment: Test JUBE

#Configuration
parameterset:
  - name: build_parameters
    parameter: 
    - {name: COMPILER,    _: "gcc:13.2.0,llvm:17.0.6"}
  - name: run_parameters
    parameter: 
    - {name: FREQ,            _: "NOMINAL,TURBO"}

#Operation
step:
  - name: prepare
    do: |
      echo "do the prepare"
  - name: build
    depend: prepare
    use: build_parameters
    do: |
      echo "do the build"
  - name: setup
    depend: build
    use: build_parameters, run_parameters
    do: |
      echo "do the build"
  - name: run
    depend: setup,build
    use: build_parameters, run_parameters
    do: |
      echo "do the build"

For the input above, the dependency of the steps would look like this :

graph TD;
    prepare-->build_gcc:13.2.0;
    build_gcc:13.2.0-->setup_gcc:13.2.0_NOMINAL;
    build_gcc:13.2.0-->setup_gcc:13.2.0_TURBO;
    setup_gcc:13.2.0_TURBO-->run_gcc:13.2.0_TURBO;
    setup_gcc:13.2.0_NOMINAL-->run_gcc:13.2.0_NOMINAL

    prepare-->build_llvm:17.0.6;
    build_llvm:17.0.6-->setup_llvm:17.0.6_NOMINAL;
    build_llvm:17.0.6-->setup_llvm:17.0.6_TURBO;
    setup_llvm:17.0.6_TURBO-->run_llvm:17.0.6_TURBO;
    setup_llvm:17.0.6_NOMINAL-->run_llvm:17.0.6_NOMINAL
Loading

However, my setup step is a bit costly in terms of compute resources, but not meaningful in terms of results (analysis): it simply produces some intermediate input from built binaries. Actually, I want to run it once only, using whatever of the build and run parameter that are specified. The dependencies I would like to express would look like this :

graph TD;
    prepare-->build_gcc:13.2.0;
    build_gcc:13.2.0-->setup_gcc:13.2.0_NOMINAL;
    setup_gcc:13.2.0_NOMINAL-->run_gcc:13.2.0_TURBO;
    setup_gcc:13.2.0_NOMINAL-->run_gcc:13.2.0_NOMINAL

    prepare-->build_llvm:17.0.6;
    build_llvm:17.0.6-->run_llvm:17.0.6_TURBO;
    build_llvm:17.0.6-->run_llvm:17.0.6_NOMINAL;
    setup_gcc:13.2.0_NOMINAL-->run_llvm:17.0.6_TURBO;
    setup_gcc:13.2.0_NOMINAL-->run_llvm:17.0.6_NOMINAL
Loading

Note that the setup is executed once for all the run steps. Because of this, some nodes have 2 parents, thus moving from tree to graph structure. I would like something like this :

  - name: setup
    depend: build
    use: build_parameters[0], run_parameters[0] # use the parameter 0 from possible values
    do: |
      echo "do the build"
  - name: run
    depend: setup,build # since there is only one instance of setup, they all depend on the same setup step; might be necessary to add support for step identification in more complex cases...
    use: build_parameters, run_parameters
    do: |
      echo "do the build"

Is there a way to specify things using JUBE ?

Best.

@thobreuer
Copy link
Collaborator

thobreuer commented Dec 11, 2023

  • Hint: since the setup step depend on the build step, the parametersets used in the build will automatically be available in the setup step without using them explicitly (see my example below).
  • What you are probably looking for is a shared step with a shared do as a solution for the setup step. JUBE will still create the four directories (as in your first graph), but the shared do will only be executed once in the shared directory define in the step shared attribute for all four workpackages of the setup step. See also our adv. tutorial section about shared-operations: https://apps.fz-juelich.de/jsc/jube/jube2/docu/advanced.html#shared-operations
name: testjube
outpath: testjube_bench
comment: TEST

#Configuration
parameterset:
  - name: build_parameters
    parameter:
    - {name: COMPILER,    _: "gcc:13.2.0,llvm:17.0.6"}
  - name: run_parameters
    parameter:
    - {name: FREQ,            _: "NOMINAL,TURBO"}

#Operation
step:
  - name: prepare
    do: |
      echo "do the prepare"
  - name: build
    depend: prepare
    use: build_parameters
    do: |
      echo "do the build: $COMPILER"
  - name: setup
    depend: build
    use: run_parameters
    shared: share
    do:
      - 'echo "do the setup: $COMPILER $FREQ"'
      - {shared: true, _: 'echo "IN SHARED"'}
  - name: run
    depend: setup
    do: |
      echo "do the run: $COMPILER $FREQ"

@antoine-morvan
Copy link
Author

antoine-morvan commented Dec 13, 2023

Thanks for pointing this ; I'll play a bit more, but it seems to be doing what I need.

In the few tries I attempted, I used - {shared: true, _: 'echo "IN SHARED $COMPILER $FREQ"'} to check which parameters are in use. If I run with

    do:
      - 'echo "do the setup: $COMPILER $FREQ"'
      - {shared: true, _: 'echo "IN SHARED  $COMPILER $FREQ"'}

The result is IN SHARED llvm:17.0.6 TURBO. But if I use

    do:
      - {shared: true, _: 'echo "IN SHARED  $COMPILER $FREQ"'}

The result is IN SHARED gcc:13.2.0 NOMINAL

Could you explain how the instance of parameter is chosen ?

On another note, it seems that the documentation refers to Operation and Step as the same thing. I was searching for "step" and "dependency" (as shared dependency), but not "operation". It's neither defined in the JUBE tutorial, nor in the avanced one. Is there any page explaining the concepts (some structure documentation, not a tutorial) ?

Best.

@thobreuer
Copy link
Collaborator

thobreuer commented Dec 20, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants