diff --git a/documentation/svmp_user_guide.html b/documentation/svmp_user_guide.html new file mode 100644 index 00000000..8b8e4bec --- /dev/null +++ b/documentation/svmp_user_guide.html @@ -0,0 +1,252 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + SimVascular Docs + + + + + + + +
+ +
+ +
+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+

+
+ + + + + + + + + + + + + + + + + + + + + diff --git a/documentation/svmp_user_guide/example_1_steady_rigid_simulation/boundary_conditions/readme.md b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/boundary_conditions/readme.md new file mode 100644 index 00000000..bd352ca6 --- /dev/null +++ b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/boundary_conditions/readme.md @@ -0,0 +1,70 @@ + +### Assigning Boundary Conditions + +The next step is to establish the boundary conditions. Boundary conditions specify the solution behavior at the exterior surfaces of the model that will be used to drive the solution. Recall from the `` section that we labeled each of the exterior surfaces according to the .vtp surface mesh files. We can now use these labels to define the boundary conditions. The figure below shows the boundary conditions we wish to specify for this model: + +
+ +
Descending Aorta model with inflow and outflow boundary conditions labeled.
+
+ +Boundary conditions are specified further down in the `` section of the .xml file: + + + + ... + + + Dirichlet + Steady + -100 + Parabolic + true + true + + + + Neumann + Resistance + 2600 + Flat + + + + Neumann + Resistance + 2600 + Flat + + + + Dirichlet + Steady + 0 + Flat + true + + + + Dirichlet + Steady + 0 + Flat + true + + +Notice how there is a separate `` section for each of the surfaces we defined earlier. The inlet face is “cap_aorta” where we wish to specify an inlet flow rate of $100 \ mL/s$. This value of $100 \ mL/s$ is slightly higher than the typical cardiac output of a healthy individual, but we round up for simplicity. Generally, you want to choose the values of your boundary conditions to match the physiologic data of the patient you are simulating. If you do not have data on specific patients, then using population average values is a reasonable assumption. + +Boundary conditions that specify velocity or flow are classified as “Dirichlet” `` boundary conditions. The flow rate at the inlet is not changing with time, so we specify its `` to “Steady”. The `` for this boundary condition is set to $-100$. We use a negative sign for the value here to specify that the flow is going into the domain. A positive flow value would have the flow exiting the domain. The `` setting specifies the spatial profile for the velocity on the face. We set this to “Parabolic” for this case to model the Hagan-Poisuelle solution for flow of a viscous fluid in a pipe. The Hagan-Poisuelle solution has the highest fluid velocity in the center of the vessel and decreases smoothly to a value of zero at the walls. To enforce the no-slip boundary condition at the walls, we set the `` setting to “true”. Finally, to specify that this boundary condition is for the flow (and not velocity), we set the `` setting to “true”. + +Next, we specify the resistance outlet boundary conditions at the two other caps of the model. Resistance outlet boundary conditions assign a pressure that is proportional to the flowrate of blood passing through the face. Resistance outlet boundary conditions are common for vascular simulations to accurately to the vascular resistance of all smaller vessels downstream of the model. The viscosity of the blood combined with the small vessel sizes requires a certain amount of pressure to push the blood through, which is proportional to the flowrate of blood: + +$$ P = QR $$ + +Where $R$ is the vascular resistance of the vessels downstream of the outlet face. Pressure boundary conditions are considered “Neumann” `` and do not change with time. We specify a resistance outlet boundary condition by assigning “Resistance” in the `` field in the boundary condition. The value of $2600 \ dynes/cm^5$ was chosen to ensure physiologic pressure values within the model. For this examples, we assume both outlet resistances are equal. Thus, we can conclude the two outlets will receive roughly equal flow of about $50 \ mL/s$. We assumed an even flow split for this example for simplicity. Later in the User Guide, we will discuss strategies for assigning a more realistic flow split between vessels by adjusting the relative resistances of the outlets. Using the equation above, we can compute the assigned outlet pressure to be: + +$$ P=(50 \ mL/s)*(2600 \ dynes/cm^5)=130000 dyne/cm^2 \approx 100 \ mmHg $$ + +$100 \ mmHg$ of pressure is roughly the average blood pressure in a healthy individual. If you have more specific physiologic data on your patient, you will want to choose your boundary condition values to match your patient data. + +The last boundary conditions we need to specify are the wall conditions. This simple simulation assumes the walls are **rigid** which means they are fixed in space. For these cases, we apply the **no slip** boundary condition which states that any fluid in direct contact with the wall will have zero velocity. For both the wall surfaces, we assign them as “Dirichlet” type boundary conditions with a value of “0”. We wish to apply this to the velocity directly, thus the `` setting, which was present for the inlet face, is missing here. \ No newline at end of file diff --git a/documentation/svmp_user_guide/example_1_steady_rigid_simulation/equations/readme.md b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/equations/readme.md new file mode 100644 index 00000000..14708d9b --- /dev/null +++ b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/equations/readme.md @@ -0,0 +1,26 @@ + +### Defining Equations and Fluid Properties + +The next step to running an *svMultiPhysics* simulation is to establish the type of equation that will be solved and to define all material properties needed. This is done in the top part of the `` section of the .xml file: + + + + true + + 1 + + 10 + + 1e-4 + + 0.3 + + 1 + + + 0.04 + + +A pure fluids simulation like this example only requires a solution to the “fluid” equation, which is specified in the `` XML command. The fluid equation only requires three properties to be defined: (1) fluid density, (2) fluid viscosity, and (3) backflow stabilization coefficient. The fluid density is assumed to be $1 \ g/cm^3$. Note that all numerical parameters in the .xml file are assumed to be consistent with each other, which should be consistent with the unit of measure established in the mesh. Based on the input mesh data for this example, we are using the CGS unit of measure. The fluid viscosity is defined within its own block where users are also able to select the viscosity model. For this simulation, we use a simple constant viscosity model with a value of 0.04 Poise for simplicity. Blood flow in the large arteries like this model can be safely assumed to be Newtonian with a constant viscosity. Blood is considered to be a non-Newtonian fluid, but the non-Newtonian behavior is typically only observed in the microvasculature where the diameter of the vessel becomes comparable to the size of the blood cells. The backflow stabilization coefficient is a parameter unique to the *svMultiPhysics* flow solver and should be kept at 0.3. + +The other parameters in this section specify settings for the nonlinear solution of the fluids governing equations. `` and `` specify how many nonlinear iterations you wish the solver to perform in each timestep. Specifying a larger amount of iterations can help the solver converge on a solution at the cost of additional simulation time. `` defines the threshold for the solution residual needed for the solver to reach convergence. If the solver achieves a solution residual at or below the tolerance, it can move onto the next timestep before reaching the maximum nonlinear iterations. Making the tolerance a smaller number will produce more accurate simulation results at the cost of additional simulation time, and vice-versa for increasing the tolerance. \ No newline at end of file diff --git a/documentation/svmp_user_guide/example_1_steady_rigid_simulation/file_management_and_miscellaneous/readme.md b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/file_management_and_miscellaneous/readme.md new file mode 100644 index 00000000..2865e2e3 --- /dev/null +++ b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/file_management_and_miscellaneous/readme.md @@ -0,0 +1,45 @@ + +### Output Control and File Management + +The final batch of settings that need to be set for a CFD simulation have to do with file management and control. *svMultiPhysics* simulations can produce a lot of output files, so it is important to specify the type and number of output files produced. These settings are located in the `` section at the top of the .xml file: + + + + ... + + results + 10 + 1 + + false + + true + + true + + results + + 10 + + 0.2 + + STOP_SIM + + false + + true + + true + + false + + + +Because of the amount and variety of settings in this section, the most useful and important settings for a general user will be listed below: + +1. `` - This specifies how often you want to save simulation outputs in terms of number of timesteps. Usually, you do not want to save results too often otherwise it will take up too much space and overwhelm a file system. But you also want to have enough time resolution to adequately analyze your results. This setting is more relevant for unsteady cases since for a steady case like this, we only need the results at the final timestep. +2. `` - Allows the simulation to skip saving results for the first few timesteps. Usually, the first few timesteps only contain initial conditions or transient results so you can skip some to save a bit of space. +3. `` - This flag will tell *svMultiPhysics* to save one file that contains time-averaged results. This can be convenient if you wish to perform time averaging across all timesteps in an unsteady simulation. +4. `` - This flag will tell *svMultiPhysics* to automatically convert simulation results to VTK format which is convenient for viewing in Paraview. + +The other settings in this section can be adjusted for more niche cases, but these are the most useful to know for a general *svMultiPhysics* simulation. \ No newline at end of file diff --git a/documentation/svmp_user_guide/example_1_steady_rigid_simulation/intro/readme.md b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/intro/readme.md new file mode 100644 index 00000000..3784aa5b --- /dev/null +++ b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/intro/readme.md @@ -0,0 +1,9 @@ + +## Example 1: Steady Fluids Simulation on Descending Aorta with Rigid Walls + +This first example will go through the steps needed to set up a steady fluids simulation on a patient-specific geometry with rigid walls and connect these with the associated commands and settings in the svMultiPhysics .xml file. All conditions in this example are assumed to be steady, meaning that they do not change with time. The flowrate of blood coming into the model will be constant as well as all other boundary conditions. Rigid walls mean that the vessel walls are assumed to be fixed with time and thus have zero velocity for the entire simulation. Both of these assumptions are not physiologically consistent with blood flow in a real patient. Flowrates and pressures fluctuate with time in a real patient due to the pulsatility of cardiac contraction and blood vessel walls are flexible that inflate and deflate along with the oscillating pressures. But we choose to start with the simplest example possible to introduce the process and format of using *svMultiPhysics*. Even for other cases, running a steady and rigid wall simulation is still useful to help debug other issues with the model or simulation setup. The subject for this example is the following patient-specific model of the descending aorta and iliac arteries. The figure below also includes the names of the exterior surfaces that we will use when assigning boundary conditions: + +
+ +
Descending Aorta model with mesh surfaces labeled.
+
\ No newline at end of file diff --git a/documentation/svmp_user_guide/example_1_steady_rigid_simulation/linear_solver/readme.md b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/linear_solver/readme.md new file mode 100644 index 00000000..3ea9d754 --- /dev/null +++ b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/linear_solver/readme.md @@ -0,0 +1,25 @@ + +### Linear Solver Parameters + +Next is to specify the parameters of the linear solver. Part of the process of numerically solving the equations of fluid mechanics involves forming a very large system of linear algebraic equations. This system of equations is too large to solve directly, so an approximate numerical solution is required. The type and settings for the linear solver can have dramatic impacts on the performance and accuracy of the CFD simulations. More detailed information about the different linear solvers and their settings included in *svMultiPhysics* can be found ***LINK_TBD***. For this simple example, we cover just the basics to get an idea of what each setting does. Linear solver settings are specified in a subsection in the `` section: + + + + ... + + + 10 + 1e-4 + 50 + 5 + 1e-4 + 500 + 1e-4 + + fsils + + + +This simulation utilizes the specialized “NS” linear solver, which is specialized for rigid wall simulations in *svMultiPhysics*. First, we will look at all the “tolerance” parameters which specify the acceptable amount of error in the different stages of the linear solver. The approximate solutions to the linear system can only be solved up to a tolerance. As the value of the tolerance is decreased, the accuracy of the computed solution will increase but it will take more time to solve for the solution. For linear solvers with multiple tolerances like this, using the same tolerance for all steps is recommended. We use a tolerance of 0.0001 for this simulation which gives fairly accurate results for a reasonable cost in cardiovascular settings. + +The number of iterations specifies how many times the linear solver will iterate to find a solution. Linear solver algorithms require several iterations to reach their solution. The more the linear solver is allowed to iterate, the more accurate a solution it can find at additional computational cost. But increasing the number of iterations does not necessarily mean the cost will increase. If the linear solver is able to obtain a solution that satisfies the tolerance criteria before it reaches the maximum iterations, it will cut the iterations short and move to the next step. Increasing the maximum iterations only allows it to iterate more times if it needs to. Unless your simulation is having trouble converging, we recommend keeping the number of iterations at their default values. \ No newline at end of file diff --git a/documentation/svmp_user_guide/example_1_steady_rigid_simulation/mesh/readme.md b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/mesh/readme.md new file mode 100644 index 00000000..0f770e2d --- /dev/null +++ b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/mesh/readme.md @@ -0,0 +1,39 @@ + + +### Loading Mesh and Geometry into svMultiPhysics + +The first step to running an *svMultiPhysics* simulation is to establish your geometry and mesh. You will need a volumetric mesh file (typically .vtu format) that contains the coordinates of all the nodes in the mesh as well as the element connectivity. You will also need separate mesh files for each of the exterior surfaces (typically .vtp format) that will be used to identify regions to apply boundary conditions. In the .xml input file, reading the mesh takes place in the `` section: + + + + demomesh-mesh-complete/mesh-complete.mesh.vtu + + + demomesh-mesh-complete/mesh-surfaces/cap_aorta.vtp + + + + demomesh-mesh-complete/mesh-surfaces/cap_aorta_2.vtp + + + + demomesh-mesh-complete/mesh-surfaces/cap_right_iliac.vtp + + + + demomesh-mesh-complete/mesh-surfaces/wall_aorta.vtp + + + + demomesh-mesh-complete/mesh-surfaces/wall_right_iliac.vtp + + + 0 + + + +First, the .vtu file for the volumetric mesh is loaded using the `` command. This loads in all of the nodal coordinates and connectivities for the mesh nodes and elements. Next, each of the exterior face meshes are loaded with `` commands. These are used to label certain exterior surfaces on the mesh so that we can apply different boundary conditions on them later on. Notice how each of these commands references a specific file inside a folder called “mesh-complete”. When running *svMultiPhysics*, it is important that the relative path to the mesh files stays consistent with how they are defined in the .xml file. In other words, if you wish to run the simulation from a different directory on your system, you must move BOTH the .xml file and the folder with all required input files. + +The last command in this section labels this section of the domain as “0”. For a pure fluids simulation, there is only one domain where the fluid resides. In multi-physics problems that have different domains for the solid and fluid, you can label different domains accordingly. + +At this point, we pause to discuss units. The unit system used by *svMultiPhysics* is determined by the units used when creating the geometric model and mesh. To be more specific, the units of the coordinates of all of the nodes in the mesh determine what units you should use for the rest of the parameters in *svMultiPhysics*. For example, if your model and mesh were created using centimeters as the unit of measure, then you should use CGS (centimeters-grams-seconds) for all other parameters in *svMultiPhysics*. \ No newline at end of file diff --git a/documentation/svmp_user_guide/example_1_steady_rigid_simulation/outputs/readme.md b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/outputs/readme.md new file mode 100644 index 00000000..c2ae8819 --- /dev/null +++ b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/outputs/readme.md @@ -0,0 +1,14 @@ + +### Specifying Output Quantities + +After the boundary conditions and time marching parameters are specified, the next step is to specify the types of output quantities we would like from the simulation. Different output quantities can be selected based on the information you are aiming to obtain from the simulation. By default, the velocity and pressure fields are output since they are the primary outputs from a fluids simulation. Wall shear stress (WSS) is also a common output for cardiovascular simulations due to its correlation with vascular cell growth and remodeling. The outputs are specified within a subsection of the `` section of the .xml file: + + + + ... + + + true + true + true + diff --git a/documentation/svmp_user_guide/example_1_steady_rigid_simulation/running_svmp/readme.md b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/running_svmp/readme.md new file mode 100644 index 00000000..10b74104 --- /dev/null +++ b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/running_svmp/readme.md @@ -0,0 +1,20 @@ + +### Running svMultiPhysics from Terminal + +When the .xml input file is ready, you can run your simulation from the command line terminal by running the *svMultiPhysics* application. If you have installed *svMultiPhysics* from the .deb installation package, the application should be found in the following location: + + /usr/local/sv/svMultiPhysics/2026-06-11/bin/svmultiphysics + +This example uses the version of *svMultiPhysics* published on 2026-06-11. Note that if you installed a different version of *svMultiPhysics*, the path to the executable will have a different date. If you are having trouble locating your *svMultiPhysics* executable, you can try the following command to search for the installation folder: + + ls /usr/local/sv/svMultiPhysics/ + +This should show you the installation folders for the version of *svMultiPhysics* that you have. If you have multiple versions, they should be denoted by their dates. Replace the date in your application path to the appropriate one. + +After you have identified your *svMultiPhysics* application, you can run the simulation by running it from the folder where the .xml input file is located. Navigate to the folder where your .xml file is, then run the following command: + + [svmultiphysics_executable] [name_of_xml_input_file] + +For example, if your input file were called demo_simulation.xml and if you are using the 2026-06-11 version, the command to run the simulation would be: + + /usr/local/sv/svMultiPhysics/2026-06-11/bin/svmultiphysics demo_simulation.xml \ No newline at end of file diff --git a/documentation/svmp_user_guide/example_1_steady_rigid_simulation/runtime/readme.md b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/runtime/readme.md new file mode 100644 index 00000000..92273be8 --- /dev/null +++ b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/runtime/readme.md @@ -0,0 +1,17 @@ + +### Checking Simulation during Runtime + +After launching your simulation, you can check the terminal window to see how it is doing. If the simulation is diverging or taking too long, you can stop the simulation and address any issues instead of waiting until it reaches the end: + +
+ +
Sample Terminal Output when running svMultiPhysics.
+
+ +Each column has different information about the simulation as it progresses. We will list some of the most important columns here and how to interpret them. + +1. NS xx-xx - The first two letters in this column expresses the current equation that is being solved. Since this simulation is purely fluids, the only equation that gets solved is the Navier-Stokes (NS) equation. The next two numbers next to this show the current timestep and the nonlinear iterations within that timestep. The screenshot above reaches convergence in four nonlinear iterations so it moves onto the next timestep instead of going to the maximum of ten. The simulation will reach its conclusion when the timestep reaches the maximum specified under the `` +2. The next number immediately to the right of this column shows the amount of walltime that has elapsed since the simulation began in seconds. The 30th timestep in the simulation above started at 1892 real life seconds since the simulation began. +3. The second number inside the [] square brackets expresses the **residual** of the current solution. The residual is an expression of the error in the current numerical solution. More specifically, it shows the discrepancy when plugging in the current numerical solution into the governing equations. Since the numerical solution is not exact, there will always be a difference when plugging back into the governing equation. This number starts at 1.0 at the beginning of each timestep and should reduce upon each nonlinear iteration within that timestep. When this number dips below the tolerance specified in the .xml file, the simulation moves onto the next timestep. The first number in the square brackets shows the decrease in the residual in dB format. + +Keeping an eye on the simulation residual is the most important to make sure the simulation is adequately converging. If you observe the residual is not decreasing fast enough within a timestep or even starts to increase, it would be best to stop the simulation and **decrease the timestep size** to help the simulation converge. If you do reduce the timestep size, make sure to also adjust the number of timesteps to ensure the amount of simulated time stays the same. For example, if you halve the timestep size, you need to double the number of timesteps. To stop a simulation from the command line terminal, hit `Ctrl+C` on the keyboard. \ No newline at end of file diff --git a/documentation/svmp_user_guide/example_1_steady_rigid_simulation/sim_outputs/readme.md b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/sim_outputs/readme.md new file mode 100644 index 00000000..bae89867 --- /dev/null +++ b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/sim_outputs/readme.md @@ -0,0 +1,25 @@ + +### Checking Simulation Outputs + +When your simulation finishes, the results can be viewed by loading the .vtu result files into a 3D viewing software like **Paraview**. Different simulations with different geometries and different boundary conditions will all have different results. But even so, all fluids simulations will exhibit certain features that are expected. It is usually a good idea to do a quick sanity checks for these expected results to ensure the simulation ran properly. If your solution does not exhibit these general features, it is a good indication to check all the inputs to ensure the simulation was setup correctly. First, let’s check the velocity field: + +
+ +
Velocity field results on the walls from svMultiPhysics simulation with rigid walls.
+
+ +Notice how the entire model appears blue, which is zero velocity according to the color legend. This makes sense since we assumed our simulation to have rigid walls and no slip. If a deformable wall simulation were performed, the wall would have motion and velocity. If you rotate the model to view the caps, you should see there is nonzero velocity there. These nonzero velocities show that blood flow is coming out at these caps. + +
+ +
Velocity field results on the outlet caps from svMultiPhysics simulation.
+
+ +Next, it is useful to check the pressure distribution in the model. In general, we expect pressure to be highest at the inlets of the model and lowest at the outlets of the model. The decrease in pressure from the inlets to the outlets is a result of the energy needed to overcome viscous friction in the 3D domain: + +
+ +
Pressure field results on the from a svMultiPhysics simulation.
+
+ +There may be other factors that produce local increases or decreases in pressure like sudden changes in the vessel radius or deformable walls. But you should observe a general decrease of pressure from inlets to outlets. These general solution characteristics should be present for any rigid wall simulation and are good to check before performing any further analysis. If you do not observe these solution behaviors, it could be an indication that something went wrong with the simulation and you need to re-run it with adjusted parameters. \ No newline at end of file diff --git a/documentation/svmp_user_guide/example_1_steady_rigid_simulation/time_marching/readme.md b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/time_marching/readme.md new file mode 100644 index 00000000..e62f132d --- /dev/null +++ b/documentation/svmp_user_guide/example_1_steady_rigid_simulation/time_marching/readme.md @@ -0,0 +1,18 @@ + +### Time Marching Parameters ### + +Our next step is to specify the time marching parameters. This is done in the `` section at the top of the .xml file. *svMultiPhysics* simulations are solved one discrete timestep at a time, with each timestep of the simulation separated by a fixed amount of time. This is analogous to how a digital video is shown one frame at a time where each frame is separated by a fixed amount of time. We need to specify how many timesteps we wish to solve in our simulation as well as the timestep size: + + + + 3 + 100 + 1e-3 + +The timestep size specifies how much time will pass in between timesteps. This parameter should be chosen to give enough time resolution to capture the phenomena you are trying to model. It should also be sufficiently small to ensure accurate simulation results. Similar to the mesh size, simulation accuracy goes up as the timestep size decreases (at additional computational time and cost). We choose a timestep size of 1 ms (0.001 seconds) for this example, which is a good starting point for cardiovascular simulations. Another good rule of thumb for selecting the timestep size is to use the CFL condition: + +$$ CFL = v * \Delta t / \Delta x < 1 $$ + +Here, $v$ is a characteristic velocity in the simulation, $\Delta x$ is the grid spacing for the mesh, and $\Delta t$ is the timestep size. The CFL number should be less than 1 at all points and all times for solution stability. An unstable solution will *diverge*, meaning the errors will grow exponentially until nonsensical numbers are computed. The stability of a simulation can be checked in real time by observing the *residual*, which will be explained in a future section. The CFL number is normally hard to compute exactly for a given simulation since the grid spacing is not uniform and the velocity changes at different locations in a simulation. But it is useful to know that smaller grid sizes (which are sometimes needed for more accurate results) require a smaller timestep size for a stable solution. If you find that your simulations are diverging, then try **reducing the timestep size** and re-running the simulation to see if that helps. + +The number of timesteps then ultimately determines the total simulation time. For this simple simulation, we are simulating 100 timesteps at 0.001 seconds each, so the total simulation time is (100 timesteps)(0.001 s/timestep) = 0.1 s. Since all our boundary conditions are steady, we only need to simulate a small amount of time to eliminate transient effects from the initial conditions. But if your boundary conditions are changing with time (ex: you have a pulsatile inflow), you will need to simulate a larger number of timesteps to fully capture the behavior you wish. This will be expanded upon in future examples with pulsatile inflow boundary conditions. \ No newline at end of file diff --git a/documentation/svmp_user_guide/img/svmp_ug_ex1_model_and_bc.png b/documentation/svmp_user_guide/img/svmp_ug_ex1_model_and_bc.png new file mode 100644 index 00000000..8ff48bbe Binary files /dev/null and b/documentation/svmp_user_guide/img/svmp_ug_ex1_model_and_bc.png differ diff --git a/documentation/svmp_user_guide/img/svmp_ug_ex1_model_and_surfaces.png b/documentation/svmp_user_guide/img/svmp_ug_ex1_model_and_surfaces.png new file mode 100644 index 00000000..064ca5bb Binary files /dev/null and b/documentation/svmp_user_guide/img/svmp_ug_ex1_model_and_surfaces.png differ diff --git a/documentation/svmp_user_guide/img/svmp_ug_ex1_results_pressure.png b/documentation/svmp_user_guide/img/svmp_ug_ex1_results_pressure.png new file mode 100644 index 00000000..38bb4ffd Binary files /dev/null and b/documentation/svmp_user_guide/img/svmp_ug_ex1_results_pressure.png differ diff --git a/documentation/svmp_user_guide/img/svmp_ug_ex1_results_velocity_1.png b/documentation/svmp_user_guide/img/svmp_ug_ex1_results_velocity_1.png new file mode 100644 index 00000000..cfd2cb86 Binary files /dev/null and b/documentation/svmp_user_guide/img/svmp_ug_ex1_results_velocity_1.png differ diff --git a/documentation/svmp_user_guide/img/svmp_ug_ex1_results_velocity_2.png b/documentation/svmp_user_guide/img/svmp_ug_ex1_results_velocity_2.png new file mode 100644 index 00000000..cdfaf019 Binary files /dev/null and b/documentation/svmp_user_guide/img/svmp_ug_ex1_results_velocity_2.png differ diff --git a/documentation/svmp_user_guide/img/svmp_ug_ex1_terminal_output.png b/documentation/svmp_user_guide/img/svmp_ug_ex1_terminal_output.png new file mode 100644 index 00000000..c795e3bd Binary files /dev/null and b/documentation/svmp_user_guide/img/svmp_ug_ex1_terminal_output.png differ diff --git a/documentation/svmp_user_guide/introduction/readme.md b/documentation/svmp_user_guide/introduction/readme.md new file mode 100644 index 00000000..185cb7d9 --- /dev/null +++ b/documentation/svmp_user_guide/introduction/readme.md @@ -0,0 +1,6 @@ + +# *svMultiPhysics* User Guide + +## Introduction + +The purpose of this User Guide is to provide users with information and best practices for setting up simulations in *svMultiPhysics*. Specifically, the User Guide will explain each conceptual step needed to set up a simulation along with the commands needed to execute each step in the *svMultiPhysics* .xml input file. This guide is designed to be independent of the front-end SimVascular interface so that *svMultiPhysics* can be used to set up a simulation if provided the right input files. The examples will proceed with increasing complexity ranging from simple steady flow simulations with rigid walls to unsteady deformable wall simulations. If you have any questions or if anything is unclear, please do not hesitate to contact us through the public forums!