Enhance documentation for backend-agnostic solver and structs design; clarify usage and custom field specifications

Author: ZenanH

docs/src/interface/backendagnostic.md

@@ -1,8 +1,8 @@
 # Backend-agnostic solver
 
-MaterialPointSolver.jl is a high-performance solver that is backend-agnostic, meaning we only need to write a unified codebase that can run on different accelerator backends. The main computational process of the solver relies on kernel functions implemented by [KernelAbstractions.jl](https://github.com/JuliaGPU/KernelAbstractions.jl), so users do not need to worry about the data migration process from the CPU to other hardware backends. 
+***MaterialPointSolver.jl*** is a high-performance solver that is backend-agnostic, meaning we only need to write a unified codebase that can run on different accelerator backends. The main computational process of the solver relies on kernel functions implemented by [KernelAbstractions.jl](https://github.com/JuliaGPU/KernelAbstractions.jl), so users do not need to worry about the data migration process from the CPU to other hardware backends. 
 
-Users should use MaterialPointSolver.jl, and then selects the backend based on your hardware, for example:
+Users should use ***MaterialPointSolver.jl***, and then selects the backend based on your hardware, for example:
 
 ```julia-repl
 julia> using MaterialPointSolver
@@ -13,21 +13,6 @@ julia> using CUDA
 # using oneAPI # for Intel gpu
 ```
 
-Taking the CUDA backend as an example, we define automatic conversion methods in `/ext/CUDAExt/devicehelpfunc_cuda.jl`: `host2device` for transferring data to the device, and `device2host!` for downloading data back to the CPU from the backend.
-
-!!! note
-
-    The reason this solution can succeed is that the structs' (including custom structs) fields only contain `scalar` and `array` types for the kernel function, and currently do not support other forms.
-
-Although Julia has a garbage collection mechanism to automatically reclaim memory, we hope to clean up GPU memory usage promptly after each simulation. Currently, in `/ext/CUDAExt/devicehelpfunc_cuda.jl`, we use the function `clean_device!` to do this.
-
 !!! note
-    
-    For all functions related to the accelerated backend that are not part of the MPM process, a dedicated implementation may be required in the `/ext` folder.
-
-!!! todo
 
-    Currently,
-    1) Memory clean can only be achieved on the Nvidia platform, and other platforms are waiting for it to provide the relevant API.
-    2) Metal on the Apple platform does not support FP64 computation precision.  
-    3) Intel's GPU devices have not been tested, but the code implementation should be relatively easy. Ideally, it should only require filling in some parts of the `/ext` folder.
+    In addition to selecting the appropriate backend package, users must also specify the backend when instantiating `Config`, which will be explained in later sections.

docs/src/interface/structs.md

@@ -1,17 +1,19 @@
 # Structs design
 
-!!! note
+The solver provides three main struct types: 1) **Configurations**, 2) **Background grid**, 3) **Material particles**.
+
+**Configurations** use the `Config` type and store settings such as simulation time, adaptive time stepping, whether to save results as HDF5, etc.
+
+The **Background grid** uses the `DeviceGrid` type and stores information such as grid size, spacing, and number of nodes. Only structured grids are supported.
 
-    Here is an interactive graph to illustrate the basic structs in this solver.
-    
-```@raw html
-<iframe frameborder="0" style="width:100%;height:993px;" src="https://viewer.diagrams.net/?lightbox=1&target=blank&highlight=0000ff&nav=1&title=types.drawio&transparent=1&dark=1#Uhttps%3A%2F%2Fdrive.google.com%2Fuc%3Fid%3D12XsHGS7FoGt8cuzTLdUagSsZHNrODts8%26export%3Ddownload" allowtransparency="true"></iframe>
-```
+**Material particles** use the `DeviceParticle` type and represent the discrete particles of the model, storing quantities such as particle count, velocity, stress, and more.
 
-Green blocks are structs that users need to interact with, and they follow a similar hierarchical logic. To maximize support for users to easily implement custom algorithms, we have added an Extra structure to each structure. For example, for `Particle`, it is `UserParticleExtra`.
+Both `DeviceGrid` and `DeviceParticle` support the plugin system. If the default fields are not sufficient (which is true in most cases), users may add custom fields.
 
 !!! note
 
-    Although `Args` has a user-customizable struct called `UserArgsExtra`, like other `Args`, it cannot be directly used as input for the kernel function; it can only pass its values (bits) to the kernel function.
+    Custom fields can only be scalar or array types of Real, e.g., `(custom1 = 1.2, custom2 = rand(10, 2))`.
+
+!!! note
 
-When the user instantiates green blocks, the data will be automatically transferred between different computing backends based on the user's selection. For internal information about the types, please refer to the source code.
+    You are responsible for specifying the numerical precision of custom fields.