The default settings of Threads.@threads changed to :dynamic scheduling with Julia 1.8, which leads to wrong results.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Add documentation for developers with instructions how to implement new material models and how to use the interfaces.

Add docstrings to all functions and specify if a function is not part of the public API.

A tracker for anything that needs to be implemented or changed in the code base for v0.3.0:

• #55
• #53
• #43
• #42
• #28
• #65
• #66
• #69
• #72
• #73
• #74
• #77
• #79
• #83
• #86

See https://github.com/julia-actions/cache#usage for more details

Current approach

The bottleneck of Peridynamics simulations lies in the computation of the force density b_int (see the compute_forcedensity! methods). In the serial case, this computation looks similar to the following code:

for (i,j) in bonds
    results = some_calculation()
    b_int[:,i] += results # contribution for point i
    b_int[:,j] -= results # contribution for point j
end

Since the computation writes into columns i and j of the b_int matrix, it cannot be easily parallelized. Therefore, the force density is extended by one dimension, and each thread operates on its own 2D matrix. Finally, all the results are summed up into the first column efficiently. Currently, this and other computations are implemented using Threads.@threads, where each thread operates on its own partition of the corresponding vector.

#--- main computation
@threads for tid in 1:nthreads()
    for bond_id in partitioned_bonds[tid] 
        i, j = bonds[bond_id]
        results = some_calculation()
	b_int[:,i,tid] += results # <-- tid = third dimension
	b_int[:,j,tid] -= results # <-- tid = third dimension
    end
end

#--- reduction into first tid
# single_tids::Vector{Tuple{Int,Int}} 
# --> vector containing tuples with (<point id>, <thread id>) 
#     for all points where the computations occur on only one thread (except 1)
@threads for (point_id, tid) in single_tids
    b_int[:,point_id,1] = b_int[:,point_id,tid]
end
# multi_tids::Vector{Tuple{Int,Vector{Int}}
# --> vector containing tuples with (<point id>, <vector of all thread id's except 1>)
#     for all points where the computations occur on multiple threads
@threads for (point_id, tids) in multi_tids
    for tid in tids
        b_int[:,point_id,1] += b_int[:,point_id,tid]
    end
end

#---
# usage of b_int[:,:,1] ...

Benchmark

However, the scaling for more than ten threads is not good, even with the improvements in the summation (see #9 (comment)).

Roadmap

The main goal is to make the package suitable for larger HPC simulations. The significant RAM requirements for simulations with ContinuumBasedMaterial are also a limiting factor for the multithreading approach. Therefore, an effective solution could be using a distributed approach with MPI.jl in combination with Multithreading (similar to Trixi.jl). Alternatively, other options such as Dagger.jl look very promising.

Improve the logging and printing of infos during simulation.

Since multithreading is explicitly configured in the current code (with tid in most cases), should this line be explicit about the specific thread as well?

https://github.com/kfrb/Peridynamics.jl/blob/4110dd2c62853464314eb617e95b84697f5276c1/src/peridynamics_base.jl#L869

Less text & more concise. Add infos regarding MPI + Threads and maybe an example overview like in the docs.

Created as a follow-up of #69, the definition of material models can be further enhanced by macros for defining material parameters and storages.

Keywords in some docstrings are preceded by a colon, which needs to be corrected.

e.g.:

Add the penalty based contact algorithm used in version v0.2.

Interested in getting this repo included? A PR or an issue would be welcome...

Check the names of the test files that all are named test_<file in src>.

There exists test_bond_discretization.jl which refers to the old name.

Delete all old sections and anything related to the old version of the package from the documentation.

Provide a custom MaterialInterfaceError that has a clearer message than the currently used MethodError when someone forgot to correctly specify the interface for a new Material.

The definition of a new material involves a lot of boilerplate code that could be created with a macro.

Hi !
I was using the peridynamics.jl package to model a contact simulation with the predefined crack in the target. But I am getting the following issue:
MethodError: no method matching PDContactAnalysis(; name::String, body_setup::Vector{BodySetup}, contact::Vector{Contact}, td::VelocityVerlet, es::ExportSettings, precracks::Peridynamics.PreCrack)

Closest candidates are:
PDContactAnalysis(; name, body_setup, contact, td, es) got unsupported keyword argument "precracks"
@ Peridynamics C:\Users\PC.julia\packages\Peridynamics\X60e3\src\contact.jl:71

Stacktrace:
[1] kwerr(kw::NamedTuple{(:name, :body_setup, :contact, :td, :es, :precracks), Tuple{String, Vector{BodySetup}, Vector{Contact}, VelocityVerlet, ExportSettings, Peridynamics.PreCrack}}, args::Type)
@ Base .\error.jl:165
[2] top-level scope
@ In[11]:1.
Can you please help me with it.

Thank you.

Remove private types and type parameters in docstrings.

e.g.:

Make important abstract types like AbstractMaterial public and add documentation to these types.

A tracker for all documentation related tasks:

• #35
• #37
• #39
• #40
• #41
• #44
• #45
• #47
• #49
• #50
• #52
• #56
• #57
• #58
• #59
• #60
• #61
• #63
• #76
• #81
• #82
• #92

Some of the exported MPI-related functions are currently not documented.

The link to the following image is broken:

All links to the images in this file are also broken:

docs/src/continuumbased.md

Add a type parameter to all structs to have generic storage field type and material parameters.
The type parameter should pre promoted by the specified position and volume given to Body.

Add a type parameter, e.g., NDIMS, to all relevant structs and define methods for 1D, 2D, and 3D simulations, where needed.

@JuliaRegistrator register

In some julia-repl code example blocks, an additional line needs to be inserted, which will then be similar to the REPL.

e.g.:

Automate the creation of point_data_field functions with the help of maybe the req_storage_fields_* functions.

After #53 is closed, all julia-repl examples need to be updated regarding the new output in the REPL.

The neighborhood search of TrixiParticles.jl is faster than the current approach with NearestNeighbors.jl and better suited for contact simulations.

Update the currently working tutorials to the new API.

• Mode I tension dynamic with fracture
• Mode I tension with predefined crack

Add some examples to the documentation regarding the new feature of precracks as described in #31.

Make the usage of upper and lower case consistent across the documentation.

All sentences and descriptions should start with upper case.

Link to the image of the logo is broken:

name: 💡 Enhancement Request
about: Request an enhancement or clarification on pre-cracked surfaces
title: '[ENHANCEMENT] Clarification on pre-cracked surfaces'

Requested Enhancement/Clarification:

1. First, thank you, @kaipartmann, for putting together such a nice and well-written peridynamic implementation.
2. I would like to better understand the pre-crack option per the example on tutorial_tension_precrack:
   I noticed that the pre-cracked area gets a damage value when initially placed. Say the damage variable equals 0.5 on the nodes at the edge and less towards the inner portion of the body. However, I believe the pre-cracked surfaces should be "undamaged" at the beginning of the simulation. The only difference with respect to the other neighbors is that these nodes on the crack surfaces have fewer neighbors compared to the bulk of the material. Is this how it is intended to be (as-is)?

Anything else:

tutorial_tension_precrack

Add the dynamic relaxation time solver as used in v0.2.

Hello, do you have an idea for a fatigue model?
It would be great to make this board

If a halo field gets specified as export field with the fields keyword argument in Job, the halo field has an incorrect length for the export as VTKPointData.

The tutorials overview at the home section of the documentation does not look good on mobile devices.

The equations in the theory section of the documentation can be simplified and more consistent. In particular the equations for OSB-PD.

Hi @kaipartmann

We're working on the thermo-mechanical coupling model. A script from scratch is here (https://github.com/vavrines/KitPD.jl/blob/main/couple/script.jl).
We're just about to clean and refactor the codes. The idea is to reuse the structs and methods here as much as possible.
I'd like to know if you're interested in implementing this functionality. If things go well, we should be able to contribute codes, but your assistance will likely be needed.

Add tests for:

@JuliaRegistrator register

The read_inp function of the submodule AbaqusMeshConverter does not return a PointCloud and is not exported, as in v0.2.
To use an Abaqus mesh for the simulations, one has to specifically load the submodule with

using Peridynamics.AbaqusMeshConverter

or has to use Peridynamics.read_inp. Therefore, the current workflow is similar to the following:

using Peridynamics
using Peridynamics.AbaqusMeshConverter

position, volume, point_sets = read_inp("path/to/abaqus_inp_file.inp")
body = Body(BBMaterial(), position, volume)

# for point sets, 1. either specify every set by hand:
point_set!(body, :some_set, point_sets["some_set"])
# ... all other sets

# or 2. use a for loop:
for (set_name, point_ids) in point_sets
    point_set!(body, Symbol(set_name), point_ids)
end

New method for Body:

It would be relatively easy to implement the code above into a new method for Body. Then the mentioned workflow would be much easier:

using Peridynamics

# the point sets are already included without specifying!
body = Body(BBMaterial(), "path/to/abaqus_inp_file.inp")

Coverage should be increased to at least >95%.

Maybe we should consider to add volume and surface correction, as discussed in #32.

The fields of exported structs like Body or Job should be considered implementation details, which should be recognizable in their docstrings.

• new gifs for tutorials need to be created
• image creation with GLMakie
  docs/src/literate/tutorial_tension_precrack.jl

Add custom methods of Base.show for the public structs.

• Peridynamics.BBMaterial
• Peridynamics.CKIMaterial
• Peridynamics.OSBMaterial
• Peridynamics.NOSBMaterial
• Peridynamics.MultibodySetup
• Peridynamics.VelocityVerlet
• Peridynamics.Job