Automatic file deletion made easy #34
Closed
MAGALA-RICHARD
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
### apsimNGpy 0.39.11.20 – Release Notes
This release introduces a dedicated simulation file context manager that automatically removes transient .apsimx files and all associated output database files (.db, .db-wal, .db-sha, etc.) at the end of a with block.
This allows users to run temporary simulations with confidence that intermediate files will not accumulate on disk — especially important for large workflows, such as optimization loops, Monte Carlo runs, or multi-site batch simulations.
To achieve this, the context manager now coordinates more carefully with APSIM-NG’s I/O locking behavior. In particular, it triggers the underlying C# garbage collector (when necessary) to ensure that the write locks on the result database are fully released before deletion.
As a result, there is a small (but practically negligible) performance overhead; future versions may introduce a switch to disable this behavior for users who do not require automatic cleanup.
This release also introduces a second context manager for managing temporary APSIM bin paths.
It allows users to specify a local APSIM-NG installation path for a given script/module while preserving the global default in memory — enabling cleaner multi-version testing or workflow portability without rewriting environment variables.
### 1) Temporally simulations using a context manager
Immediately after exiting the with block, the temporary .apsimx file (and its associated .db files) are deleted,
since only clones of the original model file are used inside the context.
2) Temporary APSIM-bin path
Immediately after exiting the with block, the path is restored back to the global APSIM path — meaning that other projects and modules can continue to access their own settings normally. The importance of this pattern lies in its reproducibility, as it allows your project to be “locked” to a specific APSIM binary path.
APSIM versions change frequently, and a future run of your current project may fail or yield different results if a newer APSIM version is installed without your knowledge. By scoping a local APSIM bin path for this project, you ensure that reruns in the future use exactly the same APSIM version that generated the original results.
This makes the workflow both reproducible and stable.
The bin path can also be substituted with just the project
.envpath as followsNote
Since the model assemblies are already loaded into memory inside the
apsim_bin_context, you do not need to remain inside thewithblock to keep using them. Once loaded, those modules (and their namespaces) are global within the process, and they retaintheir reference to the APSIM bin path that was supplied during loading.
This discussion was created from the release Automatic file deletion made easy.
Beta Was this translation helpful? Give feedback.
All reactions