VMEX 0.11.3

Long CPU runs could abort, or fail with "Failed to materialize symbols", and the persistent compilation cache could be shared across machines. This release fixes both.

Fixed

• Aborts and "Failed to materialize symbols" in long runs (#467). Every compiled XLA:CPU kernel holds its own memory mappings until its executable is released, and JAX keeps every executable it compiles. A long free-boundary or optimization run on Linux can therefore reach the kernel's per-process limit vm.max_map_count (65530 on most distributions). Every further compile then fails with LLVM compilation error: Cannot allocate memory, followed by "Failed to materialize symbols" or a process abort. This happened with the compilation cache on or off. vmex now checks the mapping count after compilations. Past half the limit it releases compiled executables, which are recompiled when needed, and it warns once.
• One compilation cache per machine (#467). Cache entries are native executables. On a shared home filesystem, cluster nodes with different CPUs read the same cache, and XLA:CPU runs an entry built for another CPU after only logging "Target machine feature ... is not supported on the host machine". The cache directory now includes the host identity, so no two machines share entries; each cluster node compiles once. The path is no longer exported to child processes.
• VMEX_COMPILATION_CACHE=disabled overrides every cache setting (#467). That includes JAX_COMPILATION_CACHE_DIR and the cache JAX configures from its own environment. On jaxlib < 0.10 a cache path alone no longer turns the cache on; only VMEX_COMPILATION_CACHE=1 does.

Added

• vmex.solve_phiedge / vmex.phiedge_root: find the PHIEDGE whose free-boundary LCFS meets a geometric target, with its implicit derivative (#454).
• vmex --trace defaults and ARIES-CS --scale target updates (#472).

No configuration is needed: pip install -U vmex. Old cache directories under ~/.cache/vmex/jax_cache/ are no longer read and can be deleted.