From 49e9efd401004cb6e82549db8557f10ddda48eca Mon Sep 17 00:00:00 2001 From: "Documenter.jl" Date: Mon, 4 Sep 2023 22:11:30 +0000 Subject: [PATCH] build based on 49f077f --- dev/developers/contributing/index.html | 8 +- dev/developers/design-principles/index.html | 2 +- dev/developers/style-guide/index.html | 2 +- dev/index.html | 10 +- dev/lib/public/index.html | 8 +- dev/man/bv.svg | 80 ++++----- dev/man/energypressureplot.svg | 160 +++++++++--------- dev/man/eos.svg | 88 +++++----- dev/man/examples/index.html | 2 +- dev/man/installation/index.html | 8 +- dev/man/troubleshooting/index.html | 2 +- dev/man/units.svg | 172 ++++++++++---------- dev/search/index.html | 2 +- 13 files changed, 272 insertions(+), 272 deletions(-) diff --git a/dev/developers/contributing/index.html b/dev/developers/contributing/index.html index 6890c3f..9ea78fd 100644 --- a/dev/developers/contributing/index.html +++ b/dev/developers/contributing/index.html @@ -9,12 +9,12 @@ Deleted no artifacts, repos, packages or scratchspaces
julia> Pkg.develop("EquationOfStateRecipes") Cloning git-repo `https://github.com/MineralsCloud/EquationOfStateRecipes.jl.git` Resolving package versions... Updating `~/work/EquationOfStateRecipes.jl/EquationOfStateRecipes.jl/docs/Project.toml` - [8d49d7c9] ~ EquationOfStateRecipes v0.5.0 `~/work/EquationOfStateRecipes.jl/EquationOfStateRecipes.jl` ⇒ v0.5.1 `~/.julia/dev/EquationOfStateRecipes` + [8d49d7c9] ~ EquationOfStateRecipes v0.5.1 `~/work/EquationOfStateRecipes.jl/EquationOfStateRecipes.jl` ⇒ v0.5.1 `~/.julia/dev/EquationOfStateRecipes` Updating `~/work/EquationOfStateRecipes.jl/EquationOfStateRecipes.jl/docs/Manifest.toml` - [8d49d7c9] ~ EquationOfStateRecipes v0.5.0 `~/work/EquationOfStateRecipes.jl/EquationOfStateRecipes.jl` ⇒ v0.5.1 `~/.julia/dev/EquationOfStateRecipes`

Then the package will be cloned to your local machine. On *nix systems, the default path is ~/.julia/dev/EquationOfStateRecipes unless you modify the JULIA_DEPOT_PATH environment variable. If you're on Windows, this will be C:\\Users\\<my_name>\\.julia\\dev\\EquationOfStateRecipes. In the following text, we will call it PKGROOT.

Go to PKGROOT, start a new Julia session, and run

julia> using Pkg
julia> Pkg.instantiate()Precompiling project...
+  [8d49d7c9] ~ EquationOfStateRecipes v0.5.1 `~/work/EquationOfStateRecipes.jl/EquationOfStateRecipes.jl` ⇒ v0.5.1 `~/.julia/dev/EquationOfStateRecipes`

Then the package will be cloned to your local machine. On *nix systems, the default path is ~/.julia/dev/EquationOfStateRecipes unless you modify the JULIA_DEPOT_PATH environment variable. If you're on Windows, this will be C:\\Users\\<my_name>\\.julia\\dev\\EquationOfStateRecipes. In the following text, we will call it PKGROOT.

Go to PKGROOT, start a new Julia session, and run

julia> using Pkg
julia> Pkg.instantiate()Precompiling project...
   ✓ EquationOfStateRecipes
   ✓ EquationOfStateRecipes → PlotsExt
-  2 dependencies successfully precompiled in 9 seconds. 180 already precompiled.
+  2 dependencies successfully precompiled in 13 seconds. 180 already precompiled.
   2 dependencies precompiled but different versions are currently loaded. Restart julia to access the new versions

to instantiate the project.

Step 4: checkout a new branch

Note

In the following, replace any instance of GITHUB_ACCOUNT with your GitHub username.

The next step is to check out a development branch. In a terminal (or command prompt on Windows), run:

$ cd ~/.julia/dev/EquationOfStateRecipes
 
 $ git remote add GITHUB_ACCOUNT https://github.com/GITHUB_ACCOUNT/EquationOfStateRecipes.jl.git
@@ -47,4 +47,4 @@
 
 $ git checkout main
 
-$ git pull
Note

If you have suggestions to improve this guide, please make a pull request! It's particularly helpful if you do this after your first pull request because you'll know all the parts that could be explained better.

Thanks for contributing to EquationOfStateRecipes!

+$ git pull
Note

If you have suggestions to improve this guide, please make a pull request! It's particularly helpful if you do this after your first pull request because you'll know all the parts that could be explained better.

Thanks for contributing to EquationOfStateRecipes!

diff --git a/dev/developers/design-principles/index.html b/dev/developers/design-principles/index.html index c9a349f..76e40f8 100644 --- a/dev/developers/design-principles/index.html +++ b/dev/developers/design-principles/index.html @@ -13,4 +13,4 @@ end return y end

and thus using such a macro as the interface is not preferred when possible. However, a macro like @muladd is trivial to picture on a code (it recursively transforms a*b + c to muladd(a,b,c) for more accuracy and efficiency), so using such a macro for example:

julia> @macroexpand(@muladd k3 = f(t + c3 * dt, @. uprev + dt * (a031 * k1 + a032 * k2)))
-:(k3 = f((muladd)(c3, dt, t), (muladd).(dt, (muladd).(a032, k2, (*).(a031, k1)), uprev)))

is recommended. Some macros in this category are:

Some performance macros, like @simd, @threads, or @turbo from LoopVectorization.jl, make an exception in that their generated code may be foreign to many users. However, they still are classified as appropriate uses as they are syntactic sugar since they do (or should) not change the behavior of the program in measurable ways other than performance.

Errors should be caught as early as possible, and error messages should be made contextually clear for newcomers

Whenever possible, defensive programming should be used to check for potential errors before they are encountered deeper within a package. For example, if one knows that f(u0,p) will error unless u0 is the size of p, this should be caught at the start of the function to throw a domain specific error, for example "parameters and initial condition should be the same size".

Subpackaging and interface packages is preferred over conditional modules via Requires.jl

Requires.jl should be avoided at all costs. If an interface package exists, such as ChainRulesCore.jl for defining automatic differentiation rules without requiring a dependency on the whole ChainRules.jl system, or RecipesBase.jl which allows for defining Plots.jl plot recipes without a dependency on Plots.jl, a direct dependency on these interface packages is preferred.

Otherwise, instead of resorting to a conditional dependency using Requires.jl, it is preferred one creates subpackages, i.e. smaller independent packages kept within the same GitHub repository with independent versioning and package management. An example of this is seen in Optimization.jl which has subpackages like OptimizationBBO.jl for BlackBoxOptim.jl support.

Some important interface packages to be aware of include:

Functions should either attempt to be non-allocating and reuse caches, or treat inputs as immutable

Mutating codes and non-mutating codes fall into different worlds. When a code is fully immutable, the compiler can better reason about dependencies, optimize the code, and check for correctness. However, many times a code making the fullest use of mutation can outperform even what the best compilers of today can generate. That said, the worst of all worlds is when code mixes mutation with non-mutating code. Not only is this a mishmash of coding styles, it has the potential non-locality and compiler proof issues of mutating code while not fully benefiting from the mutation.

Out-of-place and immutability is preferred when sufficient performant

Mutation is used to get more performance by decreasing the amount of heap allocations. However, if it's not helpful for heap allocations in a given spot, do not use mutation. Mutation is scary and should be avoided unless it gives an immediate benefit. For example, if matrices are sufficiently large, then A*B is as fast as mul!(C,A,B), and thus writing A*B is preferred (unless the rest of the function is being careful about being fully non-allocating, in which case this should be mul! for consistency).

Similarly, when defining types, using struct is preferred to mutable struct unless mutating the struct is a common occurrence. Even if mutating the struct is a common occurrence, see whether using Setfield.jl is sufficient. The compiler will optimize the construction of immutable structs, and thus this can be more efficient if it's not too much of a code hassle.

Tests should attempt to cover a wide gamut of input types

Code coverage numbers are meaningless if one does not consider the input types. For example, one can hit all the code with Array, but that does not test whether CuArray is compatible! Thus, it's always good to think of coverage not in terms of lines of code but in terms of type coverage. A good list of number types to think about are:

Array types to think about testing are:

When in doubt, a submodule should become a subpackage or separate package

Each package should focus on one core idea. If there's something separate enough to be a submodule, could it instead be a separate well-tested and documented package to be used by other packages? Most likely yes.

Globals should be avoided whenever possible

Global variables should be avoided whenever possible. When required, global variables should be constants and have an all uppercase name separated with underscores (e.g. MY_CONSTANT). They should be defined at the top of the file, immediately after imports and exports but before an __init__ function. If you truly want mutable global style behavior you may want to look into mutable containers.

Type-stable and type-grounded code is preferred wherever possible

Type-stable and type-grounded code helps the compiler create not only more optimized code, but also faster to compile code. Always keep containers well-typed, functions specializing on the appropriate arguments, and types concrete.

Closures should be avoided whenever possible

Closures can cause accidental type instabilities that are difficult to track down and debug; in the long run it saves time to always program defensively and avoid writing closures in the first place, even when a particular closure would not have been problematic. A similar argument applies to reading code with closures; if someone is looking for type instabilities, this is faster to do when code does not contain closures. See examples here.

Furthermore, if you want to update variables in an outer scope, do so explicitly with Refs or self defined structs.

Numerical functionality should use the appropriate generic numerical interfaces

While you can use A\b to do a linear solve inside a package, that does not mean that you should. This interface is only sufficient for performing factorizations, and so that limits the scaling choices, the types of A that can be supported, etc. Instead, linear solves within packages should use LinearSolve.jl. Similarly, nonlinear solves should use NonlinearSolve.jl. Optimization should use Optimization.jl. Etc. This allows the full generic choice to be given to the user without depending on every solver package (effectively recreating the generic interfaces within each package).

Functions should capture one underlying principle

Functions mean one thing. Every dispatch of + should be "the meaning of addition on these types". While in theory you could add dispatches to + that mean something different, that will fail in generic code for which + means addition. Thus, for generic code to work, code needs to adhere to one meaning for each function. Every dispatch should be an instantiation of that meaning.

Internal choices should be exposed as options whenever possible

Whenever possible, numerical values and choices within scripts should be exposed as options to the user. This promotes code reusability beyond the few cases the author may have expected.

Prefer code reuse over rewrites whenever possible

If a package has a function you need, use the package. Add a dependency if you need to. If the function is missing a feature, prefer to add that feature to said package and then add it as a dependency. If the dependency is potentially troublesome, for example because it has a high load time, prefer to spend time helping said package fix these issues and add the dependency. Only when it does not seem possible to make the package "good enough" should using the package be abandoned. If it is abandoned, consider building a new package for this functionality as you need it, and then make it a dependency.

Prefer to not shadow functions

In Julia, two functions can share the same name if they belong to different namespaces. For example, X.f and Y.f can be two different functions, with different dispatches, but the same name. This should be avoided whenever possible. Instead of creating MyPackage.sort, consider adding dispatches to Base.sort for your types if these new dispatches match the underlying principle of the function. If they don't, it would be preferable to use a different name. While using MyPackage.sort is not conflicting, it is going to be confusing for most people unfamiliar with your code, so MyPackage.special_sort would be more helpful to newcomers reading the code.

+:(k3 = f((muladd)(c3, dt, t), (muladd).(dt, (muladd).(a032, k2, (*).(a031, k1)), uprev)))

is recommended. Some macros in this category are:

Some performance macros, like @simd, @threads, or @turbo from LoopVectorization.jl, make an exception in that their generated code may be foreign to many users. However, they still are classified as appropriate uses as they are syntactic sugar since they do (or should) not change the behavior of the program in measurable ways other than performance.

Errors should be caught as early as possible, and error messages should be made contextually clear for newcomers

Whenever possible, defensive programming should be used to check for potential errors before they are encountered deeper within a package. For example, if one knows that f(u0,p) will error unless u0 is the size of p, this should be caught at the start of the function to throw a domain specific error, for example "parameters and initial condition should be the same size".

Subpackaging and interface packages is preferred over conditional modules via Requires.jl

Requires.jl should be avoided at all costs. If an interface package exists, such as ChainRulesCore.jl for defining automatic differentiation rules without requiring a dependency on the whole ChainRules.jl system, or RecipesBase.jl which allows for defining Plots.jl plot recipes without a dependency on Plots.jl, a direct dependency on these interface packages is preferred.

Otherwise, instead of resorting to a conditional dependency using Requires.jl, it is preferred one creates subpackages, i.e. smaller independent packages kept within the same GitHub repository with independent versioning and package management. An example of this is seen in Optimization.jl which has subpackages like OptimizationBBO.jl for BlackBoxOptim.jl support.

Some important interface packages to be aware of include:

Functions should either attempt to be non-allocating and reuse caches, or treat inputs as immutable

Mutating codes and non-mutating codes fall into different worlds. When a code is fully immutable, the compiler can better reason about dependencies, optimize the code, and check for correctness. However, many times a code making the fullest use of mutation can outperform even what the best compilers of today can generate. That said, the worst of all worlds is when code mixes mutation with non-mutating code. Not only is this a mishmash of coding styles, it has the potential non-locality and compiler proof issues of mutating code while not fully benefiting from the mutation.

Out-of-place and immutability is preferred when sufficient performant

Mutation is used to get more performance by decreasing the amount of heap allocations. However, if it's not helpful for heap allocations in a given spot, do not use mutation. Mutation is scary and should be avoided unless it gives an immediate benefit. For example, if matrices are sufficiently large, then A*B is as fast as mul!(C,A,B), and thus writing A*B is preferred (unless the rest of the function is being careful about being fully non-allocating, in which case this should be mul! for consistency).

Similarly, when defining types, using struct is preferred to mutable struct unless mutating the struct is a common occurrence. Even if mutating the struct is a common occurrence, see whether using Setfield.jl is sufficient. The compiler will optimize the construction of immutable structs, and thus this can be more efficient if it's not too much of a code hassle.

Tests should attempt to cover a wide gamut of input types

Code coverage numbers are meaningless if one does not consider the input types. For example, one can hit all the code with Array, but that does not test whether CuArray is compatible! Thus, it's always good to think of coverage not in terms of lines of code but in terms of type coverage. A good list of number types to think about are:

Array types to think about testing are:

When in doubt, a submodule should become a subpackage or separate package

Each package should focus on one core idea. If there's something separate enough to be a submodule, could it instead be a separate well-tested and documented package to be used by other packages? Most likely yes.

Globals should be avoided whenever possible

Global variables should be avoided whenever possible. When required, global variables should be constants and have an all uppercase name separated with underscores (e.g. MY_CONSTANT). They should be defined at the top of the file, immediately after imports and exports but before an __init__ function. If you truly want mutable global style behavior you may want to look into mutable containers.

Type-stable and type-grounded code is preferred wherever possible

Type-stable and type-grounded code helps the compiler create not only more optimized code, but also faster to compile code. Always keep containers well-typed, functions specializing on the appropriate arguments, and types concrete.

Closures should be avoided whenever possible

Closures can cause accidental type instabilities that are difficult to track down and debug; in the long run it saves time to always program defensively and avoid writing closures in the first place, even when a particular closure would not have been problematic. A similar argument applies to reading code with closures; if someone is looking for type instabilities, this is faster to do when code does not contain closures. See examples here.

Furthermore, if you want to update variables in an outer scope, do so explicitly with Refs or self defined structs.

Numerical functionality should use the appropriate generic numerical interfaces

While you can use A\b to do a linear solve inside a package, that does not mean that you should. This interface is only sufficient for performing factorizations, and so that limits the scaling choices, the types of A that can be supported, etc. Instead, linear solves within packages should use LinearSolve.jl. Similarly, nonlinear solves should use NonlinearSolve.jl. Optimization should use Optimization.jl. Etc. This allows the full generic choice to be given to the user without depending on every solver package (effectively recreating the generic interfaces within each package).

Functions should capture one underlying principle

Functions mean one thing. Every dispatch of + should be "the meaning of addition on these types". While in theory you could add dispatches to + that mean something different, that will fail in generic code for which + means addition. Thus, for generic code to work, code needs to adhere to one meaning for each function. Every dispatch should be an instantiation of that meaning.

Internal choices should be exposed as options whenever possible

Whenever possible, numerical values and choices within scripts should be exposed as options to the user. This promotes code reusability beyond the few cases the author may have expected.

Prefer code reuse over rewrites whenever possible

If a package has a function you need, use the package. Add a dependency if you need to. If the function is missing a feature, prefer to add that feature to said package and then add it as a dependency. If the dependency is potentially troublesome, for example because it has a high load time, prefer to spend time helping said package fix these issues and add the dependency. Only when it does not seem possible to make the package "good enough" should using the package be abandoned. If it is abandoned, consider building a new package for this functionality as you need it, and then make it a dependency.

Prefer to not shadow functions

In Julia, two functions can share the same name if they belong to different namespaces. For example, X.f and Y.f can be two different functions, with different dispatches, but the same name. This should be avoided whenever possible. Instead of creating MyPackage.sort, consider adding dispatches to Base.sort for your types if these new dispatches match the underlying principle of the function. If they don't, it would be preferable to use a different name. While using MyPackage.sort is not conflicting, it is going to be confusing for most people unfamiliar with your code, so MyPackage.special_sort would be more helpful to newcomers reading the code.

diff --git a/dev/developers/style-guide/index.html b/dev/developers/style-guide/index.html index 1c20c74..9e91e92 100644 --- a/dev/developers/style-guide/index.html +++ b/dev/developers/style-guide/index.html @@ -5,4 +5,4 @@ julia> using JuliaFormatter: format -julia> format("docs"); format("src"); format("test")
Info

A continuous integration check verifies that all PRs made to EquationOfStateRecipes have passed the formatter.

The following sections outline extra style guide points that are not fixed automatically by JuliaFormatter.

Use the Julia extension for Visual Studio Code

Please use Visual Studio Code with the Julia extension to edit, format, and test your code. For the time being, we do not recommend using editors other than Visual Studio Code to edit your code.

This extension already has JuliaFormatter integrated. So to format your code, follow the steps listed here.

+julia> format("docs"); format("src"); format("test")
Info

A continuous integration check verifies that all PRs made to EquationOfStateRecipes have passed the formatter.

The following sections outline extra style guide points that are not fixed automatically by JuliaFormatter.

Use the Julia extension for Visual Studio Code

Please use Visual Studio Code with the Julia extension to edit, format, and test your code. For the time being, we do not recommend using editors other than Visual Studio Code to edit your code.

This extension already has JuliaFormatter integrated. So to format your code, follow the steps listed here.

diff --git a/dev/index.html b/dev/index.html index 5325c76..b41ae60 100644 --- a/dev/index.html +++ b/dev/index.html @@ -1,12 +1,12 @@ EquationOfStateRecipes · EquationOfStateRecipes.jl
Edit on GitHub

EquationOfStateRecipes

Documentation for EquationOfStateRecipes.

See the Index for the complete list of documented functions and types.

The code, which is hosted on GitHub, is tested using various continuous integration services for its validity.

This repository is created and maintained by @singularitti, and contributions are highly welcome.

Package features

This package contains recipes for EquationsOfStateOfSolids.jl which work with Plots.jl.

Installation

The package can be installed with the Julia package manager. From the Julia REPL, type ] to enter the Pkg mode and run:

pkg> add EquationOfStateRecipes

Or, equivalently, via Pkg.jl:

julia> import Pkg; Pkg.add("EquationOfStateRecipes")   Resolving package versions...
-   Installed EquationOfStateRecipes ─ v0.5.0
+   Installed EquationOfStateRecipes ─ v0.5.1
     Updating `~/work/EquationOfStateRecipes.jl/EquationOfStateRecipes.jl/docs/Project.toml`
-  [8d49d7c9] ~ EquationOfStateRecipes v0.5.1 `~/.julia/dev/EquationOfStateRecipes` ⇒ v0.5.0
+  [8d49d7c9] ~ EquationOfStateRecipes v0.5.1 `~/.julia/dev/EquationOfStateRecipes` ⇒ v0.5.1
     Updating `~/work/EquationOfStateRecipes.jl/EquationOfStateRecipes.jl/docs/Manifest.toml`
-  [8d49d7c9] ~ EquationOfStateRecipes v0.5.1 `~/.julia/dev/EquationOfStateRecipes` ⇒ v0.5.0
+  [8d49d7c9] ~ EquationOfStateRecipes v0.5.1 `~/.julia/dev/EquationOfStateRecipes` ⇒ v0.5.1
 Precompiling project...
   ✓ EquationOfStateRecipes
   ✓ EquationOfStateRecipes → PlotsExt
-  2 dependencies successfully precompiled in 9 seconds. 180 already precompiled.
-  2 dependencies precompiled but different versions are currently loaded. Restart julia to access the new versions

Documentation

  • STABLE — documentation of the most recently tagged version.
  • DEV — documentation of the in-development version.

Project status

The package is developed for and tested against Julia v1.6 and above on Linux, macOS, and Windows.

Questions and contributions

You can post usage questions on our discussion page.

We welcome contributions, feature requests, and suggestions. If you encounter any problems, please open an issue. The Contributing page has a few guidelines that should be followed when opening pull requests and contributing code.

Manual outline

Library outline

Index

+ 2 dependencies successfully precompiled in 13 seconds. 180 already precompiled. + 2 dependencies precompiled but different versions are currently loaded. Restart julia to access the new versions

Documentation

Project status

The package is developed for and tested against Julia v1.6 and above on Linux, macOS, and Windows.

Questions and contributions

You can post usage questions on our discussion page.

We welcome contributions, feature requests, and suggestions. If you encounter any problems, please open an issue. The Contributing page has a few guidelines that should be followed when opening pull requests and contributing code.

Manual outline

Library outline

Index

diff --git a/dev/lib/public/index.html b/dev/lib/public/index.html index 82bbec3..3c2a147 100644 --- a/dev/lib/public/index.html +++ b/dev/lib/public/index.html @@ -7,10 +7,10 @@ plot!(eos::BulkModulusEquation, volumes, args...; kw...) plot!(plotobj, eos::EnergyEquation, volumes, args...; kw...) plot!(plotobj, eos::PressureEquation, volumes, args...; kw...) -plot!(plotobj, eos::BulkModulusEquation, volumes, args...; kw...)

Plot the energy/pressure/bulk modulus versus volumes curve given an equation of state.

source
EquationOfStateRecipes.energyplot — Function
energyplot(params::Parameters, volumes, args...; kw...)
+plot!(plotobj, eos::BulkModulusEquation, volumes, args...; kw...)

Plot the energy/pressure/bulk modulus versus volumes curve given an equation of state.

source
EquationOfStateRecipes.energyplot — Function
energyplot(params::Parameters, volumes, args...; kw...)
 energyplot!(params::Parameters, volumes, args...; kw...)
-energyplot!(plotobj, params::Parameters, volumes, args...; kw...)

Plot the energy versus volumes curves given the parameters of equations of state.

source
EquationOfStateRecipes.pressureplot — Function
pressureplot(params::Parameters, volumes, args...; kw...)
+energyplot!(plotobj, params::Parameters, volumes, args...; kw...)

Plot the energy versus volumes curves given the parameters of equations of state.

source
EquationOfStateRecipes.pressureplot — Function
pressureplot(params::Parameters, volumes, args...; kw...)
 pressureplot!(params::Parameters, volumes, args...; kw...)
-pressureplot!(plotobj, params::Parameters, volumes, args...; kw...)

Plot the pressure versus volumes curves given the parameters of equations of state.

source
EquationOfStateRecipes.bulkmodulusplot — Function
bulkmodulusplot(params::Parameters, volumes, args...; kw...)
+pressureplot!(plotobj, params::Parameters, volumes, args...; kw...)

Plot the pressure versus volumes curves given the parameters of equations of state.

source
EquationOfStateRecipes.bulkmodulusplot — Function
bulkmodulusplot(params::Parameters, volumes, args...; kw...)
 bulkmodulusplot!(params::Parameters, volumes, args...; kw...)
-bulkmodulusplot!(plotobj, params::Parameters, volumes, args...; kw...)

Plot the bulk modulus versus volumes curves given the parameters of equations of state.

source
+bulkmodulusplot!(plotobj, params::Parameters, volumes, args...; kw...)

Plot the bulk modulus versus volumes curves given the parameters of equations of state.

source diff --git a/dev/man/bv.svg b/dev/man/bv.svg index f9449b3..b9fd36a 100644 --- a/dev/man/bv.svg +++ b/dev/man/bv.svg @@ -1,54 +1,54 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/dev/man/energypressureplot.svg b/dev/man/energypressureplot.svg index 093812e..fdf6714 100644 --- a/dev/man/energypressureplot.svg +++ b/dev/man/energypressureplot.svg @@ -1,98 +1,98 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/dev/man/eos.svg b/dev/man/eos.svg index 60c5925..243c922 100644 --- a/dev/man/eos.svg +++ b/dev/man/eos.svg @@ -1,58 +1,58 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/dev/man/examples/index.html b/dev/man/examples/index.html index d757de6..cac9920 100644 --- a/dev/man/examples/index.html +++ b/dev/man/examples/index.html @@ -49,4 +49,4 @@ GKS: can't connect to GKS socket application GKS: Open failed in routine OPEN_WS -GKS: GKS not in proper state. GKS must be either in the state WSOP or WSAC in routine ACTIVATE_WS

+GKS: GKS not in proper state. GKS must be either in the state WSOP or WSAC in routine ACTIVATE_WS

diff --git a/dev/man/installation/index.html b/dev/man/installation/index.html index a33d443..a933cdb 100644 --- a/dev/man/installation/index.html +++ b/dev/man/installation/index.html @@ -12,13 +12,13 @@ Updating git-repo `https://github.com/MineralsCloud/EquationOfStateRecipes.jl` Resolving package versions... Updating `~/work/EquationOfStateRecipes.jl/EquationOfStateRecipes.jl/docs/Project.toml` - [8d49d7c9] ~ EquationOfStateRecipes v0.5.0 ⇒ v0.5.1 `https://github.com/MineralsCloud/EquationOfStateRecipes.jl#main` + [8d49d7c9] ~ EquationOfStateRecipes v0.5.1 ⇒ v0.5.1 `https://github.com/MineralsCloud/EquationOfStateRecipes.jl#main` Updating `~/work/EquationOfStateRecipes.jl/EquationOfStateRecipes.jl/docs/Manifest.toml` - [8d49d7c9] ~ EquationOfStateRecipes v0.5.0 ⇒ v0.5.1 `https://github.com/MineralsCloud/EquationOfStateRecipes.jl#main` + [8d49d7c9] ~ EquationOfStateRecipes v0.5.1 ⇒ v0.5.1 `https://github.com/MineralsCloud/EquationOfStateRecipes.jl#main` Precompiling project... ✓ EquationOfStateRecipes ✓ EquationOfStateRecipes → PlotsExt - 2 dependencies successfully precompiled in 9 seconds. 180 already precompiled. + 2 dependencies successfully precompiled in 12 seconds. 180 already precompiled. 2 dependencies precompiled but different versions are currently loaded. Restart julia to access the new versions

in the second step above.

Update the package

Please watch our GitHub repository for new releases. Once we release a new version, you can update EquationOfStateRecipes by typing

julia> using Pkg
julia> Pkg.update("EquationOfStateRecipes")    Updating registry at `~/.julia/registries/General.toml`
     Updating git-repo `https://github.com/MineralsCloud/EquationOfStateRecipes.jl`
   No Changes to `~/work/EquationOfStateRecipes.jl/EquationOfStateRecipes.jl/docs/Project.toml`
@@ -29,4 +29,4 @@
 
 julia> Pkg.rm("EquationOfStateRecipes")
 
-julia> Pkg.gc()

  • Press Ctrl+D to quit the current session. Start a new Julia session and reinstall EquationOfStateRecipes.

    • +julia> Pkg.gc()

  • Press Ctrl+D to quit the current session. Start a new Julia session and reinstall EquationOfStateRecipes.

    • diff --git a/dev/man/troubleshooting/index.html b/dev/man/troubleshooting/index.html index b5744f5..9858f5e 100644 --- a/dev/man/troubleshooting/index.html +++ b/dev/man/troubleshooting/index.html @@ -1,2 +1,2 @@ -Troubleshooting · EquationOfStateRecipes.jl
    Edit on GitHub

    Troubleshooting

    This page collects some possible errors you may encounter along with tips on how to fix them. If you have some questions about how to use this code, you are welcome to discuss with us.

    If you have additional tips, please either report an issue or submit a pull request with suggestions.

    Cannot find the Julia executable

    Make sure you have Julia installed in your environment. Please download the latest stable version for your platform. If you are using a *nix system, the recommended way is to use Juliaup. If you do not want to install Juliaup or you are using other platforms that Julia supports, download the corresponding binaries. Then, create a symbolic link to the Julia executable. If the path is not in your $PATH environment variable, export it to your $PATH.

    Some clusters, like Comet, or Expanse, already have Julia installed as a module, you may just module load julia to use it. If not, either install by yourself or contact your administrator.

    See Installation Guide for more information.

    Julia starts slow

    First, we recommend you download the latest version of Julia. Usually, the newest version has the best performance.

    If you need to use Julia for a simple, one-time task, you can start the Julia REPL with

    julia --compile=min

    to minimize compilation or

    julia --optimize=0

    to minimize optimizations, or just use both. Or you could make a system image and run with

    julia --sysimage custom-image.so

    See Fredrik Ekre's talk for details.

    +Troubleshooting · EquationOfStateRecipes.jl
    Edit on GitHub

    Troubleshooting

    This page collects some possible errors you may encounter along with tips on how to fix them. If you have some questions about how to use this code, you are welcome to discuss with us.

    If you have additional tips, please either report an issue or submit a pull request with suggestions.

    Cannot find the Julia executable

    Make sure you have Julia installed in your environment. Please download the latest stable version for your platform. If you are using a *nix system, the recommended way is to use Juliaup. If you do not want to install Juliaup or you are using other platforms that Julia supports, download the corresponding binaries. Then, create a symbolic link to the Julia executable. If the path is not in your $PATH environment variable, export it to your $PATH.

    Some clusters, like Comet, or Expanse, already have Julia installed as a module, you may just module load julia to use it. If not, either install by yourself or contact your administrator.

    See Installation Guide for more information.

    Julia starts slow

    First, we recommend you download the latest version of Julia. Usually, the newest version has the best performance.

    If you need to use Julia for a simple, one-time task, you can start the Julia REPL with

    julia --compile=min

    to minimize compilation or

    julia --optimize=0

    to minimize optimizations, or just use both. Or you could make a system image and run with

    julia --sysimage custom-image.so

    See Fredrik Ekre's talk for details.

    diff --git a/dev/man/units.svg b/dev/man/units.svg index 6343c27..b285acc 100644 --- a/dev/man/units.svg +++ b/dev/man/units.svg @@ -1,104 +1,104 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/dev/search/index.html b/dev/search/index.html index ac47310..514f9a9 100644 --- a/dev/search/index.html +++ b/dev/search/index.html @@ -1,2 +1,2 @@ -Search · EquationOfStateRecipes.jl

    Loading search...

      +Search · EquationOfStateRecipes.jl

      Loading search...