diff --git a/dev/.documenter-siteinfo.json b/dev/.documenter-siteinfo.json index c2e1f5d..52ea1fd 100644 --- a/dev/.documenter-siteinfo.json +++ b/dev/.documenter-siteinfo.json @@ -1 +1 @@ -{"documenter":{"julia_version":"1.9.3","generation_timestamp":"2023-10-08T21:29:01","documenter_version":"1.1.0"}} \ No newline at end of file +{"documenter":{"julia_version":"1.9.3","generation_timestamp":"2023-10-08T22:48:08","documenter_version":"1.1.0"}} \ No newline at end of file diff --git a/dev/developers/contributing/index.html b/dev/developers/contributing/index.html index 3bf86d1..93c1906 100644 --- a/dev/developers/contributing/index.html +++ b/dev/developers/contributing/index.html @@ -9,9 +9,9 @@ Deleted no artifacts, repos, packages or scratchspaces
julia> Pkg.develop("MillerIndices") Cloning git-repo `https://github.com/MineralsCloud/MillerIndices.jl.git` Resolving package versions... Updating `~/work/MillerIndices.jl/MillerIndices.jl/docs/Project.toml` - [f41335bc] ~ MillerIndices v0.2.0 `~/work/MillerIndices.jl/MillerIndices.jl` ⇒ v0.3.0 `~/.julia/dev/MillerIndices` + [f41335bc] ~ MillerIndices v0.3.0 `~/work/MillerIndices.jl/MillerIndices.jl` ⇒ v0.3.0 `~/.julia/dev/MillerIndices` Updating `~/work/MillerIndices.jl/MillerIndices.jl/docs/Manifest.toml` - [f41335bc] ~ MillerIndices v0.2.0 `~/work/MillerIndices.jl/MillerIndices.jl` ⇒ v0.3.0 `~/.julia/dev/MillerIndices`

Then the package will be cloned to your local machine. On *nix systems, the default path is ~/.julia/dev/MillerIndices unless you modify the JULIA_DEPOT_PATH environment variable. If you're on Windows, this will be C:\\Users\\<my_name>\\.julia\\dev\\MillerIndices. 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...
+  [f41335bc] ~ MillerIndices v0.3.0 `~/work/MillerIndices.jl/MillerIndices.jl` ⇒ v0.3.0 `~/.julia/dev/MillerIndices`

Then the package will be cloned to your local machine. On *nix systems, the default path is ~/.julia/dev/MillerIndices unless you modify the JULIA_DEPOT_PATH environment variable. If you're on Windows, this will be C:\\Users\\<my_name>\\.julia\\dev\\MillerIndices. 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...
   ✓ MillerIndices
   1 dependency successfully precompiled in 1 seconds. 27 already precompiled.
   1 dependency precompiled but a different version is currently loaded. Restart julia to access the new version

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/MillerIndices
@@ -46,4 +46,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 MillerIndices!

+$ 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 MillerIndices!

diff --git a/dev/developers/design-principles/index.html b/dev/developers/design-principles/index.html index 18ce8c4..96a0048 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 fde6152..28b139d 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 MillerIndices 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 MillerIndices 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 d80bd32..fbe8a05 100644 --- a/dev/index.html +++ b/dev/index.html @@ -3,13 +3,12 @@ m"<2, -1, -1, 3>" # MillerBravais m"(-1, 0, 1)" # ReciprocalMiller m"(1, 0, -1, 0)" # ReciprocalMillerBravais

  • List equivalent directions/planes

  • Conversion between Miller and Miller-Bravais representations

  • Calculate angles between indices

  • Interplanar spacing calculation

    • 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 MillerIndices

    Or, equivalently, via Pkg.jl:

    julia> import Pkg; Pkg.add("MillerIndices")   Resolving package versions...
-   Installed MillerIndices ─ v0.1.0
+   Installed MillerIndices ─ v0.3.0
     Updating `~/work/MillerIndices.jl/MillerIndices.jl/docs/Project.toml`
-⌃ [f41335bc] ~ MillerIndices v0.3.0 `~/.julia/dev/MillerIndices` ⇒ v0.1.0
+  [f41335bc] ~ MillerIndices v0.3.0 `~/.julia/dev/MillerIndices` ⇒ v0.3.0
     Updating `~/work/MillerIndices.jl/MillerIndices.jl/docs/Manifest.toml`
-⌃ [f41335bc] ~ MillerIndices v0.3.0 `~/.julia/dev/MillerIndices` ⇒ v0.1.0
-        Info Packages marked with ⌃ have new versions available and may be upgradable.
+  [f41335bc] ~ MillerIndices v0.3.0 `~/.julia/dev/MillerIndices` ⇒ v0.3.0
 Precompiling project...
   ✓ MillerIndices
   1 dependency successfully precompiled in 1 seconds. 27 already precompiled.
-  1 dependency precompiled but a different version is currently loaded. Restart julia to access the new version

    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

    + 1 dependency precompiled but a different version is currently loaded. Restart julia to access the new version

    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/internals/abstract/index.html b/dev/lib/internals/abstract/index.html index eab642d..b0c61e9 100644 --- a/dev/lib/internals/abstract/index.html +++ b/dev/lib/internals/abstract/index.html @@ -1,2 +1,2 @@ -Abstract types · MillerIndices.jl
    +Abstract types · MillerIndices.jl
    diff --git a/dev/lib/public/index.html b/dev/lib/public/index.html index 95f18e0..c884dd0 100644 --- a/dev/lib/public/index.html +++ b/dev/lib/public/index.html @@ -1,9 +1,9 @@ -Public API · MillerIndices.jl

    Public API

    Contents

    Index

    Public interface

    Types

    Functions and macros

    MillerIndices.familyof — Function
    familyof(x::Union{Miller,MillerBravais,ReciprocalMiller,ReciprocalMillerBravais})

    List the all the directions/planes that are equivalent to x by symmetry.

    source
    MillerIndices.anglebtw — Function
    anglebtw(x::Miller, y::Miller, g::MetricTensor)
+Public API · MillerIndices.jl
    Public API
    Contents
    Index
    Public interface
    Types
    Functions and macros
    MillerIndices.familyof — Function
    familyof(x::Union{Miller,MillerBravais,ReciprocalMiller,ReciprocalMillerBravais})
    List the all the directions/planes that are equivalent to x by symmetry.
    source
    MillerIndices.anglebtw — Function
    anglebtw(x::Miller, y::Miller, g::MetricTensor)
 anglebtw(x::MillerBravais, y::MillerBravais, g::MetricTensor)
 anglebtw(x::ReciprocalMiller, y::ReciprocalMiller, g::MetricTensor)
 anglebtw(x::ReciprocalMillerBravais, y::ReciprocalMillerBravais, g::MetricTensor)
    Calculate the angle (in degrees) between two directions by:
    \[\cos\theta = \frac{\mathbf{x} \cdot \mathbf{y}}{\lvert\mathbf{x}\rvert \lvert\mathbf{y}\rvert}
-             = \frac{\sum_{ij} x_i g_{ij} y_j}{\sqrt{\sum_{ij} x_i g_{ij} x_j} \sqrt{\sum_{ij} y_i g_{ij} y_j}}.\]
    Note
    For the angle between two plane normals, the result is $180 - \theta$.
    source
    MillerIndices.interplanar_spacing — Function
    interplanar_spacing(x::Union{ReciprocalMiller,ReciprocalMillerBravais}, g::MetricTensor)
    Calculate the interplanar spacing by:
    \[d_{h\ k \ l} = \frac{1}{\lvert \mathbf{x}_{h\ k \ l}\rvert}.\]
    source
    CrystallographyBase.lengthof — Function
    lengthof(x::Union{AbstractMiller,AbstractMillerBravais}, g::MetricTensor)
    Calculate the magnitude of a given indices with respect to a specified metric tensor.
    source
    MillerIndices.@m_str — Macro
    m_str(s)
    Generate the Miller indices or Miller–Bravais indices quickly.
    Examples
    julia> m"[-1, 0, 1]"
+             = \frac{\sum_{ij} x_i g_{ij} y_j}{\sqrt{\sum_{ij} x_i g_{ij} x_j} \sqrt{\sum_{ij} y_i g_{ij} y_j}}.\]
    Note
    For the angle between two plane normals, the result is $180 - \theta$.
    source
    MillerIndices.interplanar_spacing — Function
    interplanar_spacing(x::Union{ReciprocalMiller,ReciprocalMillerBravais}, g::MetricTensor)
    Calculate the interplanar spacing by:
    \[d_{h\ k \ l} = \frac{1}{\lvert \mathbf{x}_{h\ k \ l}\rvert}.\]
    source
    CrystallographyBase.lengthof — Function
    lengthof(x::Union{AbstractMiller,AbstractMillerBravais}, g::MetricTensor)
    Calculate the magnitude of a given indices with respect to a specified metric tensor.
    source
    MillerIndices.@m_str — Macro
    m_str(s)
    Generate the Miller indices or Miller–Bravais indices quickly.
    Examples
    julia> m"[-1, 0, 1]"
 3-element Miller:
  -1
   0
@@ -27,4 +27,4 @@
   1
   0
  -1
-  0
    source
    
+  0
    source
    diff --git a/dev/man/examples/index.html b/dev/man/examples/index.html index 8404434..eeb8fde 100644 --- a/dev/man/examples/index.html +++ b/dev/man/examples/index.html @@ -54,4 +54,4 @@ 1
    julia> 𝐲 = ReciprocalMiller(-2, 0, 1)3-element ReciprocalMiller: -2 0 - 1
    julia> anglebtw(𝐱, 𝐲, g)41.38888526317379 + 1
    julia> anglebtw(𝐱, 𝐲, g)41.38888526317379 diff --git a/dev/man/installation/index.html b/dev/man/installation/index.html index 70b5c87..a107731 100644 --- a/dev/man/installation/index.html +++ b/dev/man/installation/index.html @@ -5,44 +5,20 @@ julia> Pkg.update() julia> Pkg.add("MillerIndices")

  • Run

    julia> using MillerIndices

    and have fun!

  • Please keep the Julia session active while using it. Restarting the session may take some time.

    • If you want to install the latest in-development (probably buggy) version of MillerIndices, type

    julia> using Pkg
    julia> Pkg.update()    Updating registry at `~/.julia/registries/General.toml`
-   Installed MillerIndices ─────── v0.2.0
-   Installed CrystallographyCore ─ v0.3.2
-   Installed CrystallographyBase ─ v0.13.0
-    Updating `~/work/MillerIndices.jl/MillerIndices.jl/docs/Project.toml`
-⌅ [93b1d1cd] ↓ CrystallographyBase v0.14.0 ⇒ v0.13.0
-  [f41335bc] ↑ MillerIndices v0.1.0 ⇒ v0.2.0
-    Updating `~/work/MillerIndices.jl/MillerIndices.jl/docs/Manifest.toml`
-⌅ [93b1d1cd] ↓ CrystallographyBase v0.14.0 ⇒ v0.13.0
-⌅ [80545937] ↓ CrystallographyCore v0.4.2 ⇒ v0.3.2
-  [f41335bc] ↑ MillerIndices v0.1.0 ⇒ v0.2.0
-        Info Packages marked with ⌅ have new versions available but compatibility constraints restrict them from upgrading. To see why use `status --outdated -m`
-Precompiling project...
-  ✓ CrystallographyCore
-  ✓ CrystallographyBase
-  ✓ MillerIndices
-  3 dependencies successfully precompiled in 3 seconds. 25 already precompiled.
-  3 dependencies precompiled but different versions are currently loaded. Restart julia to access the new versions
-  1 dependency had warnings during precompilation:
-┌ MillerIndices [f41335bc-9121-4844-b5af-1d5721981e9a]
-│  WARNING: could not import CrystallographyBase.lengthof into MillerIndices
-└  
    julia> pkg"add https://github.com/MineralsCloud/MillerIndices.jl"┌ Warning: The Pkg REPL mode is intended for interactive use only, and should not be used from scripts. It is recommended to use the functional API instead.
+  No Changes to `~/work/MillerIndices.jl/MillerIndices.jl/docs/Project.toml`
+  No Changes to `~/work/MillerIndices.jl/MillerIndices.jl/docs/Manifest.toml`
    julia> pkg"add https://github.com/MineralsCloud/MillerIndices.jl"┌ Warning: The Pkg REPL mode is intended for interactive use only, and should not be used from scripts. It is recommended to use the functional API instead.
 └ @ Pkg.REPLMode /opt/hostedtoolcache/julia/1.9.3/x64/share/julia/stdlib/v1.9/Pkg/src/REPLMode/REPLMode.jl:382
      Cloning git-repo `https://github.com/MineralsCloud/MillerIndices.jl`
     Updating git-repo `https://github.com/MineralsCloud/MillerIndices.jl`
    Resolving package versions...
     Updating `~/work/MillerIndices.jl/MillerIndices.jl/docs/Project.toml`
-  [93b1d1cd] ↑ CrystallographyBase v0.13.0 ⇒ v0.14.0
-  [f41335bc] ~ MillerIndices v0.2.0 ⇒ v0.3.0 `https://github.com/MineralsCloud/MillerIndices.jl#main`
+  [f41335bc] ~ MillerIndices v0.3.0 ⇒ v0.3.0 `https://github.com/MineralsCloud/MillerIndices.jl#main`
     Updating `~/work/MillerIndices.jl/MillerIndices.jl/docs/Manifest.toml`
-  [93b1d1cd] ↑ CrystallographyBase v0.13.0 ⇒ v0.14.0
-  [80545937] ↑ CrystallographyCore v0.3.2 ⇒ v0.4.2
-  [f41335bc] ~ MillerIndices v0.2.0 ⇒ v0.3.0 `https://github.com/MineralsCloud/MillerIndices.jl#main`
+  [f41335bc] ~ MillerIndices v0.3.0 ⇒ v0.3.0 `https://github.com/MineralsCloud/MillerIndices.jl#main`
 Precompiling project...
-  ✓ CrystallographyCore
-  ✓ CrystallographyBase
   ✓ MillerIndices
-  3 dependencies successfully precompiled in 4 seconds. 25 already precompiled.
-  3 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 MillerIndices by typing

    julia> using Pkg
    julia> Pkg.update("MillerIndices")    Updating registry at `~/.julia/registries/General.toml`
+  1 dependency successfully precompiled in 1 seconds. 27 already precompiled.
+  1 dependency precompiled but a different version is currently loaded. Restart julia to access the new version

    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 MillerIndices by typing

    julia> using Pkg
    julia> Pkg.update("MillerIndices")    Updating registry at `~/.julia/registries/General.toml`
     Updating git-repo `https://github.com/MineralsCloud/MillerIndices.jl`
   No Changes to `~/work/MillerIndices.jl/MillerIndices.jl/docs/Project.toml`
   No Changes to `~/work/MillerIndices.jl/MillerIndices.jl/docs/Manifest.toml`
    julia> Pkg.gc()      Active manifest files: 3 found
@@ -52,4 +28,4 @@
 
 julia> Pkg.rm("MillerIndices")
 
-julia> Pkg.gc()

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

    • +julia> Pkg.gc()

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

    • diff --git a/dev/man/troubleshooting/index.html b/dev/man/troubleshooting/index.html index d78d9bf..0572759 100644 --- a/dev/man/troubleshooting/index.html +++ b/dev/man/troubleshooting/index.html @@ -1,2 +1,2 @@ -Troubleshooting · MillerIndices.jl

    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 · MillerIndices.jl

    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.