remove examples project.toml

Author: szy21

docs/src/config_no_table.md

@@ -7,7 +7,7 @@ The only exception is true/false strings. These need quotes around them, or they
 
 To start the model with a custom configuration, run:
 
-`julia --project=examples examples/hybrid/driver.jl --config_file <yaml>`
+`julia --project=.buildkite .buildkite/ci_driver.jl --config_file <yaml>`
 
 ### Example
 Below is the default Bomex configuration:

docs/src/parameters.md

@@ -23,6 +23,6 @@ In the config file, enter:
 ```
 toml: parameters.toml
 ```
-In order to run the model, type: `julia --project=examples --config_file config.yaml`.
+In order to run the model, type: `julia --project=.buildkite --config_file config.yaml`.
 Note that the `--config_file` argument can take several config files, so if you have a separate config file you would like to use,
 you can simply add it to the end of the command line arguments. Alternatively, you can just add your TOML config to the existing config file.

docs/src/radiative_equilibrium.md

@@ -28,15 +28,15 @@ job_id: "single_column_radiative_equilibrium_clearsky_prognostic_surface_temp"
 
 Then run the simulation with the following command:
 ```
-julia --project=examples examples/hybrid/driver.jl --config_file path_to_mysim.yml
+julia --project=.buildkite .buildkite/ci_driver.jl --config_file path_to_mysim.yml
 ```
 
 The configuration in the yaml file above can be changed to adjust to the kind of simulation desired. Options such as t\_end can be increased to the desired simulation time. Other arguments such as radiation type can be changed based on the options in `default_config.yml`.
 
 After a simulation is ran the output files should be available in the output folder, where hdf5 files store all the simulation's data, and two mp4s should be produced with a vertical temperature profile and a vertical wind profile which change over time. If you want to quickly access data from the final day of the simulation simply add a -i to the command line input, like so:
 
 ```
-julia -i --project=examples examples/hybrid/driver.jl --config_file filepath
+julia -i --project=.buildkite .buildkite/ci_driver.jl --config_file filepath
 ```
 
 This will bring you into a julia environment where the current state of the simulation can be accessed. Run propertynames(Y) and propertynames(p) to see accessible values, some examples:

docs/src/repl_scripts.jl

@@ -18,7 +18,7 @@ function print_repl_script(config)
     ib *= """\n"""
     ib *= """config = CA.AtmosConfig(config_dict);\n"""
     ib *= """\n"""
-    ib *= """include("examples/hybrid/driver.jl")\n"""
+    ib *= """include(".buildkite/ci_driver.jl")\n"""
     println(ib)
 end
 

docs/src/single_column_prospect.md

@@ -15,9 +15,9 @@
 
 For example, to run the BOMEX test case execute the following:
 ```bash
-julia --project=examples examples/hybrid/driver.jl --config_file config/model_configs/prognostic_edmfx_bomex_column.yml --job_id bomex
+julia --project=.buildkite .buildkite/ci_driver.jl --config_file config/model_configs/prognostic_edmfx_bomex_column.yml --job_id bomex
 ```
-It may also be helpful to run in interactive mode to be able to examine the simulation object, debug, and develop the code further. To enter debug mode run `julia --project=examples` and then in the REPL run:
+It may also be helpful to run in interactive mode to be able to examine the simulation object, debug, and develop the code further. To enter debug mode run `julia --project=.buildkite` and then in the REPL run:
 ```julia
 using Revise # if you are developing ClimaAtmos
 import ClimaAtmos as CA
@@ -33,7 +33,7 @@ Currently three versions of the externally driven single column model, `GCM` dri
 ### GCM-Driven Case
 For the `GCM` driven case we can run the experiment using the config file `config/model_configs/prognostic_edmfx_gcmdriven_column.yml` by running:
 ```bash
-julia --project=examples examples/hybrid/driver.jl --config_file config/model_configs/prognostic_edmfx_gcmdriven_column.yml --job_id gcm_driven_scm
+julia --project=.buildkite .buildkite/ci_driver.jl --config_file config/model_configs/prognostic_edmfx_gcmdriven_column.yml --job_id gcm_driven_scm
 ```
 In the config the following settings are particularly important:
 ```YAML
@@ -64,7 +64,7 @@ By this point, the first 4 entries are intuitive. We need to dispatch over each
 
 The data is generated by downloading from ECMWF and further documentation for ERA5 data download can be found either directly on the ECMWF page and `ClimaArtifacts.jl`. Note that the profiles, surface temperature, and surface fluxes cannot be obtained from a single request and so together we need 3 files for all the data. We include a script at `src/utils/era5_observations_to_forcing_file.jl` which extracts the profiles and computes the tendencies needed for the simulation from the raw ERA5 reanalysis files. We store the observations directly into an artifact `era5_hourly_atmos_processed` to eliminate the need to reprocess specific sites and locations. This setup means that users are free to choose sites globally at any time at which ERA5 data is available. Unfortunately, global hourly renanalysis is too large to store in an artifact and so we have currently only provided support for the first 5 days of July 2007 in the tropical Pacific, stored in `era5_hourly_atmos_raw`, only available on the `clima` and Caltech `HPC` servers. The test case can be run using: 
 ```bash
-julia --project=examples examples/hybrid/driver.jl --config_file config/model_configs/prognostic_edmfx_tv_era5driven_column.yml --job_id era5driven
+julia --project=.buildkite .buildkite/ci_driver.jl --config_file config/model_configs/prognostic_edmfx_tv_era5driven_column.yml --job_id era5driven
 ```
 
 #### Monthly Averaged Forcing
@@ -79,7 +79,7 @@ site_latitude: 17.0
 site_longitude: -149.0
 ```
 ```bash
-julia --project=examples examples/hybrid/driver.jl --config_file config/model_configs/prognostic_edmfx_diurnal_scm_imp.yml --job_id bomex
+julia --project=.buildkite .buildkite/ci_driver.jl --config_file config/model_configs/prognostic_edmfx_diurnal_scm_imp.yml --job_id bomex
 ```
 
 #### Running the Reanalysis-driven cases at different times and locations

examples/Project.toml

@@ -1,11 +1,11 @@
 #=
 Run this script with, for example:
 ```
-julia --project=examples perf/benchmark_step.jl --h_elem 6
+julia --project=.buildkite perf/benchmark_step.jl --h_elem 6
 ```
 Or, interactively,
 ```
-julia --project=examples
+julia --project=.buildkite
 push!(ARGS, "--h_elem", "6")
 # push!(ARGS, "--device", "CPUSingleThreaded") # uncomment to run on CPU
 include(joinpath("perf", "benchmark_step.jl"));

examples/hybrid/driver.jl

@@ -8,7 +8,7 @@ using SnoopCompileCore
 invalidations = @snoop_invalidations begin
     (; config_file, job_id) = CA.commandline_kwargs()
     config = CA.AtmosConfig(config_file; job_id)
-    include(joinpath(dirname(@__DIR__), "examples", "hybrid", "driver.jl"))
+    include(joinpath(dirname(@__DIR__), ".buildkite", "ci_driver.jl"))
     nothing
 end;
 

perf/benchmark_step.jl

@@ -4,7 +4,7 @@ This document outlines how reproducibility tests work and how to update PRs to p
 
 ## The basic idea of how reproducibility tests work
 
-When a particular job opts-in to testing reproducibilitys (using the `reproducibility_test` command line option and the `julia --project=examples reproducibility_tests/test_mse.jl` command), we compare the solution dataset (the prognostic state at the last timestep) of that job with a reference dataset.
+When a particular job opts-in to testing reproducibilitys (using the `reproducibility_test` command line option and the `julia --project=.buildkite reproducibility_tests/test_mse.jl` command), we compare the solution dataset (the prognostic state at the last timestep) of that job with a reference dataset.
 
 We don't always have a reference to compare against, due to what we'll call **failure modes**. For a full list of failure modes, see [Failure modes](#Failure-modes), but here are a few examples:
 
@@ -45,7 +45,7 @@ Note: We currently do not prepend the folder names by the reference counter, how
 
 ## Allowing flaky tests
 
-Users can add the flag `test_broken_report_flakiness` to the `test_mse.jl` script: `julia --project=examples reproducibility_tests/test_mse.jl --test_broken_report_flakiness true`, which will have the following behavior:
+Users can add the flag `test_broken_report_flakiness` to the `test_mse.jl` script: `julia --project=.buildkite reproducibility_tests/test_mse.jl --test_broken_report_flakiness true`, which will have the following behavior:
 
  - If the test is not reproducible (i.e., flaky) when compared against `N` comparable references, then the test will pass and be reported as broken.
  - If the test is reproducible when compared against `N` comparable references, then the test will fail `@test_broken`, and users will be asked to fix the broken test. At which point you can remove the `--test_broken_report_flakiness true` flag from that particular job, reinforcing a strict reproducibility constraint.
@@ -64,7 +64,7 @@ To update the mse tables:
 
 To add a new reproducibility test:
 
- - Set the command-line `reproducibility_test` to true, and add `julia --color=yes --project=examples reproducibility_tests/test_mse.jl --job_id [job_id] --out_dir [job_id]` as a separate command for the new (or existing) job
+ - Set the command-line `reproducibility_test` to true, and add `julia --color=yes --project=.buildkite reproducibility_tests/test_mse.jl --job_id [job_id] --out_dir [job_id]` as a separate command for the new (or existing) job
  - Copy the `all_best_mse` dict template from the job's log
  - Paste the `all_best_mse` dict template into `reproducibility_test/reproducibility_test_job_ids.jl`
 
@@ -90,7 +90,7 @@ We cannot (easily) compare the output with a reference if we change the spatial
 
 ## A detailed procedure of how reproducibility tests are performed
 
-Reprodicibility tests are performed at the end of `examples/hybrid/driver.jl`, after a simulation completes, and relies on a unique job id (`job_id`). Here is an outline of the reproducibility test procedure:
+Reprodicibility tests are performed at the end of `.buildkite/ci_driver.jl`, after a simulation completes, and relies on a unique job id (`job_id`). Here is an outline of the reproducibility test procedure:
 
  0) Run a simulation, with a particular `job_id`, to the final time.
  1) Load a list of job IDs in `reproducibility_test_job_ids.jl`.