> For the complete documentation index, see [llms.txt](https://wiki.solids.group/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.solids.group/research-practices/student-research-guide.md). # Student Research Guide This is a comprehensive guide to get new members of the Solids Group up to speed with all the tools we use. It is written under the assumption that the new student does not have prior knowledge of C++, Python, and Linux. Thus, it provides details on very basic usages. For more advanced students, this file may still be useful for quick reference of commands that are not frequently used. All terminal commands provided here assume that you are running a Debian-based version of Linux. Exact commands may vary depending on the Linux distribution, but you should be able to google it. In addition, all commands are highlighted in blue. ## Alamo ### Install If you are new to Linux and git usage, start by making sure your computer has git installed. Open a terminal and type the following command: ``` sudo apt install git; sudo apt update; sudo apt upgrade ``` In addition, you may want to download and run the New Computer script from the Solids Group page, which can be done by using the following command on a terminal: ``` wget https://drive.google.com/file/d/1nJD3Ts8dVNCQsBHgyvVEHIyUtuXlsRsk/view; sudo bash new-computer-configure.sh ``` This file can also be accessed by going to -> Resources -> New computer configure script If you are an Alamo collaborator and have set up ssh keys to your GitHub account: Open a terminal and type ``` git clone git@github.com:solidsgroup/alamo.git ``` If you do not have those privileges: Open a terminal and type ``` git clone https://github.com/solidsgroup/alamo.git ``` ### Configure and Make Alamo has a variety of installation options. By default, it is installed in 3D mode and in production mode (i.e. not in debug mode). Different settings are accessed by adding flags to the configure file before using make. The following is an example of how to configure Alamo to 2D mode, debug mode, and to send a request to install the Eigen library, which is used by some Alamo functions. 1. Navigate to the Alamo folder, assuming you cloned Alamo to your home directory and with \ being your computer name, open a terminal and type: cd /home/\/alamo or cd \~/alamo 2. Type: ./configure --dim 2 --debug --get-eigen While the example shows the use of debug, I recommend leaving that off unless you are trying to debug an error, as this flag will cause Alamo to run slower. Once you are finished configuring Alamo, you need to "Make Alamo" in order to create the binary files and actually be able to run the software. That can be done simply by typing make on the terminal inside the Alamo directory. Note that this process can take a few minutes, and can be accelerated by using parallel processing using the j flag. For example, make -j8 which will run using 8 processors. To know how many processors you can use, check the number of cores available in your machine in the settings, type lscpu on your terminal to get that information. Make sure to always leave at least 2 free cores when running any parallel Alamo computation. ### Test Now that you have successfully installed Alamo, you can proceed to run a test case. There is a variety of working cases for different problems inside \~/alamo/tests. To run one of the tests cases, navigate to the alamo directory (cd \~/alamo) and type the following command: ``` mpirun -np 2 ./bin/alamo-2d-g++ ./tests/Eshelby/input ``` In this example, the flag -np is used to indicate the number of processors to be used for parallel computing (2 in this case). Also, note that the g++ alamo file has 2d in its name. If you did not configure using the flag --dim 2, that file name will have 3d instead. If you configure using the debug flag, the file name will be alamo-2d-debug-g++. To check the name simply navigate to \~/alamo/bin/ and type ls. The input file in Eshelby will generate an output folder in \~/alamo/tests/Eshelby/ and the results can then be visualized using VisIt. ### Input File Alamo is a large code and there is a large amount of inputs that can be provided to perform the desired simulations. Before we talk about how to write an input file, let's briefly review how Alamo handles this input file. First, you need to know which integrator you will be using. Navigate to \~/alamo/src/Integrator to check out the list of integrators that are already been implemented. Most integrators are composed of a .H file and a .cpp file. If you are not familiar with C++, .H files will generally set the scope of variables used in the integrator, without performing any calculations, by simply declaring variables and fields, their data type, and optionally a value. Additionally, the functions that will be used are also declared in the .H, without defining what they do just yet. The following image shows examples of content found inside .H files. ```cpp Set::Field temp_mf; Set::Scalar rho_ap; int mob_ap = 0; Set::Scalar q0 = 0.0; IC::IC* ic_eta; struct{ int on = 0; Set::Scalar Tref = 300.0; model_type model_ap, model_htpb; } elastic; void Advance(int lev, Set::Scalar time, Set::Scalar dt) override; ``` Once these variables are declared, their values can be modified by performing code assignments inside .cpp files, or by parsing values from an input value. To know: * Parsing functions that read from the input file are going to appear in many different files, there is no one parsing .cpp file for all variables. * It is generally good practice to include a parser for all variables that are not directly computed in the code so that the number of times you'll need to recompile the code decreases. * If alamo tries to parse a variable that does not show in the input file, it will skip that line. So it is hardly the case you have too many parsing lines. The following image is an example of how to parse a variable from the input file: ```cpp pp.query("thermal.on", value.thermal.on); pp.query("elastic.on", value.elastic.on); ``` Note that the text in quotes "thermal.on" is the variable name in the input file, while the text after `value.` is the name of the variable in the .H file. They do not have to be the same, although they will normally be. $$\int If you are starting a new integrator, be aware of the following: * For Alamo to identify new integrators, they have to be added to the \~/alamo/src/alamo.cc file. * New integrators will generally inherit from Integrator.H, and thus they should stick to the predefined set of functions inside that class. Now, the writing of an input file consists of a .txt file, where each line is one variable separated by the = sign. To know: * \# can be used to comment out a line * Do **not** use any type of line breaker (such as ; in C++) * Numbers can be parsed in scientific notation (i.e. 1.0e5) * You don't need to discriminate between string and numbers. * If a variable type is int, make sure not to add floating points (i.e. 1.0) Some common variables in most alamo input files: * `alamo.program` = name of the integrator in alamo.cc * `plot_file` = relative path to output files * `timestep` * `stop_time` * `amr.plot_int` = frequency alamo writes to output * `amr.plot_dt` = frequency alamo writes to output * `amr.n_cell` = number of cells in the most coarse level * `amr.max_level` = number of refinement levels * `geometry.prob_lo` = x y z lower values for the base box * `geometry.prob_hi` = x y z upper values for the base box Note that a full list of variables that can be parsed can be found in alamo documentation () and that the input search tool in the documentation is very useful (). The following is an example of a fully working input file content: ```ini alamo.program = mechanics plot_file = tests/Solid/output type=static timestep = 0.01 stop_time = 1.0 amr.plot_dt = 0.1 amr.max_level = 0 # amr parameters amr.n_cell = 4 4 4 amr.blocking_factor = 2 amr.thermo.int = 1 amr.thermo.plot_int = 1 # geometry geometry.prob_lo = 0 0 0 geometry.prob_hi = 1 1 1 nmodels = 1 model1.E = 210 model1.nu = 0.3 solver.verbose = 3 solver.nriters = 1 solver.max_iter = 30 bc.type = tension_test bc.tension_test.type = uniaxial_stress bc.tension_test.disp = (0,1:0,0.1) ``` ### Code Debug Alamo is a large code with thousands of lines, and debugging errors can be a very challenging task. Here are some initial ideas of how to first approach the debugging process. 1. Debug mode: when the code breaks before reaching stop\_time, backtrace files are automatically generated from alamo, in the directory the processes were run from. You'll notice that in production mode, the backtrace files are useless, and do not provide any information about what/where the problem is. If you reconfigure Alamo and compile in debug mode, running the code again with a single core, will generate a single backtrace file that has similar information to Python sigaborts backtrace. Read the file from **bottom to top**, it will often point you to what code line in your code is called to abort the process. 2. Alamo has an integrated utility tool that can be used to plot out values, abort processes, and get other information while running your code. The following is a sample of code lines to check for errors during the run and output useful information: ```cpp tempnew(i,j,k) = etanew(i,j,k) * tempsnew(i,j,k) + (1.0 - etanew(i,j,k)) * thermal.T_fluid; if (isnan(temsnew(i,j,k)) || isnan(temps(i,j,k))) { Util::Message(INFO, tempsnew(i,j,k), "tempsnew contains nan (i=",i," j=",j")"); Util::Message(INFO, temps(i,j,k), "temps contains nan (i=",i," j=",j")"); Util::Abort(INFO); } ``` The util tool also has a parallel version of Message and Abort. ### Compiling errors Because Alamo is built using several libraries, there will often be errors when compiling it for the first time. These errors may change over time based on upgrades in different libraries and of Alamo itself, making it hard to construct a list of debug approaches. However, here is a list of the first steps in debugging first-time compiling errors: * Alamo only works in Linux systems (It does work in WSL); MacOS will attempt to build Alamo but will fail due to missing requirements. * Navigate to \~/alamo/docs/requirements.txt and make sure those libraries are installed. * Linux generally carries openmpi by default, but Alamo requires the use of MPich instead. Make sure to install this library. If using an HPC, make sure to load the mpich module. (on incline you simply need to type "module load mpich"; If it fails due to openmpi being loaded, follow the instruction on screen to swap openmpi with mpich. * Install libpng using: sudo apt install libpng-dev ## VisIt ### Install VisIt documentation page has an installation guide here (). I'll add here a quick walkthrough, for the current stable version of VisIt. Be aware that this version may be outdated by the time you read this document. On a new terminal: {% code overflow="wrap" %} ```bash wget https://github.com/visit-dav/visit/releases/download/v3.3.3/visit-install3_3_3 ; wget https://github.com/visit-dav/visit/releases/download/v3.3.3/visit3_3_3.linux-x86_64-ubuntu20.tar.gz ; chmod +x visit-install3_3_3 ; ./visit-install3_3_3 3.3.3 linux-x86+64-ubuntu20 /opt/visit ; ``` {% endcode %} When prompted, select option 0. Once the installation is complete, you can either create an alias or export the PATH in the \~/.bashrc file. Example: {% code overflow="wrap" %} ``` alias visit="/opt/visit/bin/visit" ``` {% endcode %} Or export PATH=${PATH}:/opt/visit/visit3\_3\_3.linux-x86\_64/bin/ ### Basic Plots Once you completed the installation process, you can run VisIt by typing visit to a terminal (remember to start a new terminal after updating .bashrc so the changes take effect). Alamo will generate either celloutput.visit or nodeoutput.visit (or both) inside the output folder, which can then be read into VisIt. ![](/files/Tmbi8ixeep9VRDHsy2BS) You can then add plots using the Add button. There are several ways to plot data in VisIt, but we will normally use the Pseudocolor option for most plots. ![](/files/fQ6pu1RIXUcmebKJ9PL5) ### Contour You will notice that if you plot 2 variables at the same time using Pseudocolors, only the last of them will be displayed. Depending on the type of data you are trying to visualize, it may be convenient to add a contour plot, since this plot will show on top of the pseudocolor plot allowing for more data to be visualized at once. ### Isovolume Isovolume is a VisIt operator that allows you to cut off parts of the domain as you want. It is also an alternative way to visualize the data of two fields simultaneously. An example of this is when using the flame integrator, you may not be interested in the region where eta = 0 (fluid zone), and thus you can display only the "solid" region by using the isovolume to cut off eta < 0.1 while displaying the temperature profile. ![](/files/MWp8eMr3r6qdRFazjBHb) ### Annotations You'll notice that VisIt plots out a lot of annotation information that can get the screen a bit polluted. While that is not a problem for general data visualization, you may want to clean it up when creating images for papers and presentations. You can use the annotation control panel to fully customize the information that is shown, and also to move, resize, and rename the legend information. ![](/files/AwZpUcat7wfoIRRTpC51) ### Saving Content You can access the window saving setting by pressing ctrl+shift+o (or going to file -> set save options... ). This function allows you to save the current displayed window in different formats. You can also save .curve files, which are text files that contain the values of certain curves you may be displaying. This can be useful, for example, to get to the location of an interface in each time step, and then process this data on Python to generate other plots. You can also generate movies for the time evolution of the system. There are different ways of doing that, but I recommend saving png shots and then using gifski and ffmpeg to create gifs and movies. To do so, go to file -> save movie, and select the png image format. ![](/files/2iOlAviCs6oyQdxSp0bo) Now you can create a gif by going to the directory you saved the png images and using the following terminal command: {% code overflow="wrap" %} ``` gifski -o .gif visit*.png ``` {% endcode %} If you don't have gifski installed, you can install it by using `snap install gifski`. ### Python Scripting VisIt has a prompt command (CLI) that allows you to execute Python scripts to perform different actions. This can be useful, for example, when you want to extract some information from a simulation plot that has a lot of samples. You may be testing different combinations of parameters that require you to run Alamo hundreds of times, and then you have to analyze the impact on the result, and doing so for each case would be extremely time-consuming. The first step for writing a Python script is to open VisIt and record your actions inside while adding plots, and doing any other actions that you want to script for. To do so, go to controls -> commands and click record. ![](/files/QRKpCaA0YDJOFv5m9Wck) Then, proceed to do the actions you would like to automate (adding plots, operators, changing colors, annotations, etc). When you are done, click stop in the command box and VisIt will create a list of commands. ![](/files/oVGU9zMM69upcmyouzfe) You can now copy those commands to a Python file. Here is a sample of python script: PS: remember to import visit ![](/files/FuAx7BzYGk7eGd1Gd5Sp) ![](/files/akaDIhX8RILjDL0q5cg7) Now, you can execute the following command: visit -cli -nw -s pythonfile.py The -nw flag is optional, and stops VisIt from trying to launch a new window. This flag is only necessary if you are running VisIt inside of a machine that can not launch user interfaces, such as an HPC (incline). S = fluid \* eta + air \* (1-eta) ## SimBa Often when running Alamo, you will run large numbers of simulations which will create several output data folders. This will quickly make it difficult to manage and remember the difference between different simulations and whether they are relevant or not. Simba is a utility tool that helps you organize this directory using SQL. After installing and configuring, you will be able to launch a webpage that lists all the simulations and their metadata information. It also allows you to delete bad/unused results and to flag different directories according to some status/information you want. Simba is particularly useful when trying to calibrate variables and when trying to show statistical results from many sets of simulations. ### Install Navigate to the directory where you want to install Simba and clone from the repository: git clone Use pip3 to install simba: pip install -e /path/to/simba Test the installation by typing simba on the terminal. ### Configure and Usage Navigate to the project folder you want to use simba. Use the following command: simba init -i /path/to/alamo Enter the simba folder: cd .simba Open the file data.ini emacs -nw data.ini On the bottom of the page, uncomment these lines: ![](/files/kY91xSfKLokln1HlxgpQ) Change the match variable to specify the project folder. If you add it as shown in the picture it will include all output files it finds. Use the following command to have Simba read the files: simba add Use the following command to launch simba: simba web You can now open a browser and navigate to the page that is shown in the terminal: ![](/files/4bIXXWGKLTOgMTplSpsW) The page will look like this: ![](/files/IvuuBrSBzd2LA66ujRU1) Simba has several features for filtering, deleting, and organizing your files. Additionally, you are able to create new columns for variables that are not part of the input, such as the burn rate for flame simulations, which are computed in the post processing of the data. To learn how to do data, check the pack.py file in my GitHub codes repository: You can also use tags for each simulation, by clicking in the simulation hyperlink and editing the tag field: ![](/files/Ye4p91MqL7kTJZ0Q9ZG7) ## Incline Module swap openmpi4 mpich/3.3.2-ofi You can get this command updated for the current mpich version by typing module load mpich ### Generating keys ssh-keygen -t -rsa -b 4096 -C "" ### Slurm Text ![](/files/bvGGEncr5rkirzPyW7Ck) d ### Transfer data rsync \@login.incline.uccs.edu:/mmfs1/home/\/output ./\/ ## Packed Spheres ### Fixed Radii A python code that solves a packing problem for n spheres with the same radius can be found in my codes repo pack.py. This code does not use an input file, it only requires terminal flags. To run: python pack.py --radius=0.01 --pf=0.3 --seed=1 Where radius is the sphere radius, pf is the packing factor (density), and seed controls the random parameters for reproducibility. Note that the maximum sphere volume in a domain is 63% (this is a mathematical constraint). ### Random Radii Several methods can be used to perform random packing with random radii. The following a good option, as the packing code allows not only for random radii but also to control the overlap of spheres. The code works by assigning a porosity value. Git repository: Reference the code using: I have made small changes to this code to allow for more information to be printed out. You can find my version in the repo SpherePacking.cpp. To compile the code: g++ -o spheres SpherePacking.cpp To run, set up a pack.in input file and run spheres pack.in The pack.in file should look as follows: ![](/files/mGi3EAjK03NPWBt3RrUp) In this example, 400 is the number of spheres, 0.3 is the standard deviation, 0.8 is the initial porosity, 0.4 is the target porosity, the third line is the (x,y,z) domain dimensions, 5 5 5 are the number of cells in each direction, 50000 is the max iter, 1.00005 is the radius scaling factor and 1e-10 is the tolerance. ### BMP Alamo can read images and create a diffuse interface based on the level of contrast. You can create black-and-white images using Inkscape and randomly add the desired shape. After that, you can use GIMP to add a Gaussian blur to the image so that the black-to-white transition will get smoother out. If you want to use an image that was created by someone else and it has less contrast than Black-and-white images, you will need to play around with GIMP's different filters in order to create a smooth transition between the phases. ## Overleaf This section is intended to help you satisfy the group requirements and give some insights on organizing your research folders to reduce struggles. First, I recommend that you immediately start an overleaf project as if you are actively writing a paper. You obviously will not have any content to add to it initially, but this will allow you two things: 1 - Save any and all references you may come across. It is rather easy to find some important information and then never be able to find it again. Since you have the paper project, you can add the references there and write bullet points citing those papers, so it is very easy to track them back when you need them. 2 - Overleaf works as a git repository, so you should git clone it to your computer and perform all simulations inside of the repository following the group folder structure. This will save you from a lot of hassle. To git clone your repo click on menu on the top left corner and select the git option: ![](/files/iYtmBE0B5yebfh2dLIkT) Once you create your project, you will need to add the configure files and the organization folder. * Create a folder called results. * Create a folder called images. * Create a main.bib file. * Create a cas-common.cls file. * Create a cas-sc.cls file. * Create a cas-common.sty file. * Create a .gitignore file. ![](/files/ySyarPiLQzTYo18EwgEy) In the images folder, you are only going to add images that are not results. Generally, these are images that you create to support the introduction and methodology sections of your paper. In the results folder, you will create new folders for each individual results case. For example, my paper had a pure ap and a mix ap/htpb cases. Each of those cases had hundreds of simulations, all of which are performed inside the respective folder. The content of the cls and sty files and a structure for the main.tex file can be copied and pasted from here: **IMPORTANT:** Once you clone the repository to your computer, make sure to add a .gitignore file, so that you can control which files get uploaded to the cloud. Overleaf has a limit of 2000 files, and alamo simulations will easily fill that up with unnecessary files. Each simulation only needs the metadata and diff files saved to overleaf to ensure the reproducibility of your results. Here is an example of a .gitignore file: ![](/files/MuZpP5QtaNzeOhtN0CMM) Finally, remember to adhere to all writing standards described in the solid group page ## Inkscape Inkscape is an open-source vector drawing tool. It can be used to create initial condition domains for Alamo. Alamo can read both BMP and PNG format images as inputs. You can download Inkscape directly from the developer webpage inkscape.org The following is a quick example for a simple rectangular domain with a circle particle. This particle can be both a different material, when used as IC for the phi field, or a void/crack when used as IC for the eta field. Assuming my domain will be 0.2 mm x 0.1 mm, navigate to File -> Document properties... and set the width and height of the front page: ![](/files/q2Io7Le9ocj0Wkb0cQJL) Note that you don't need to set the exact dimensions of your Alamo domain, as the image read will fit the image to the domain, so as long as the proportions are kept, you won't have problems. Next, we will draw using only black and white colors so that the contrast is maximized, and it will be easier for Alamo to read the image properly. Note that the domain background displays as white but will be transparent when you export the image, so you need first to add a white rectangle. I am adding a yellow one for the sake of the example. Use the location and size tools on the top to position the square to occupy the entire domain. ![](/files/qAQteoHD1B88RelQNWE3) Next, add a circle to the image and position as desired. Use the bottom color bar to change colors and remove the borders by setting the stroke paint to none. ![](/files/jLJpkoErRuArrfxE7Qq7) Finally, use shift to select all elements, right-click and select "group". Then set the blur in the bottom left corner to 9. Note that the amount of blur will control the interface thickness, which will change the total energy at the interface when running flame, so you may need to adjust this blur. The final image should look like this: ![](/files/1tg5pBwZh9dG5Pt9bZCN) You can then click File -> Export to save it as png. If needed, you can read the svg image into gimp to save it as bmp. ## Flame This section is an intro guide for the Flame solver within Alamo, which performs the regression of Solid propellants. The two main files for this solver are \~/alamo/src/Integrators/Flame.cpp and \~/alamo/src/Integrators/Flame.H Flame.H is where all functions, variables, and fields are initialized, and their default values are set; while Flame.cpp is where all functions and models are implemented. If you are new to C++ it is worth noting that these files are supposed to follow the baseline structure of Alamo, thus two important points are to be made: 1. We generally do not create new functions; rather, we override existing functions from Alamo Integrator.H. The following functions are available in that integrator: 1. Parse() => This is where variables are read from an input file. (PS: This function is called in several files, so not all variables will be read by Flame.cpp). To add a new variable to be read, use the following: 1. pp.query("\ ", value.\); > Note that the name to be read from the input file does not need to match the name inside Alamo, though it generally does. > > Parse is also used to register new fields. Fields are essentially matrices, which will store the value of a variable for all cells or nodes of the solution domain. Beware that some variables can be solved as regular variables or as fields. This decision will impact two things: 1) for you to visualize such a variable with VisIt, it has to be a field. 2) field variables will generally compute more efficiently but at the cost of higher memory usage. It also increases the size of the output files from Alamo, which can grow very quickly (several GBs for large simulations). 2. Initialize() => Once a field is created in Parse, you need to set its value with both the initial and boundary conditions. 3. TimeStepBegin() => This function is called before the model computes the next time step. For flame, this is where the Laser field is added to the model. 4. UpdateModel() => This function is called every n time steps, where n can be defined in the input file. For Flame, this is where the Elastic solver is called. This solver is implemented in \~/alamo/src/Integrator/Base/Mechanics.H \~/alamo/src/Model/Solid/Finite/NeoHookeanPredeformed.H and NeoHookean.H 5. Advance() => This is where most of the Flame model work is implemented. 6. TagCellsForRefinement() => This is where the refinement criteria are implemented, which are based on the gradient (variation) of field variables, subjected to a tolerance that is set in the input file through variables defined in lines 79 - 82 of Flame.H 7. Regrid() => This function applies refinement to the tagged cells and is called every n timesteps, where n is defined in the input file. 8. TimeStepComplete() => This function is called in the end of the process. For Flame this is where the pressure ballistics are implemented. 9. Integrate() => This function is used to perform the integration of variables and fields. This can be used to compute a variable used somewhere else in the code and output information to thermo.dat files. 10. We use a system to name variables so that they are easy to understand: 1. struct { \ } \; 2. Additionally, variables are not defined using the C++ traditional long and double type groups, that is replaced by a Set::Scalar type so that it is standardized. (we still use int and bool types). In the following example, a1 would be called pressure.arrhenius.a1. ![](/files/jsKLHFV4PiwC3bH18b5q) Flame is currently implemented with a few solver options. First, the Elastic solver can be turned on and off by setting the values of elastic.on and elastic.type. Additionally, you can switch between the original solver and the thermal-driven solver using the variable thermal.on (Note that if thermal.on = 0 then you MUST disable the elastic solver by setting elastic.on = 0 and elastic.type = disable). Additionally, the gas phase pressure can be either a constant set value or let free to float using the variable variable\_pressure. The boundary conditions drive the direction of the regression. Here are two examples: * Left to right ![](/files/khbkILyAohRLPbIg5qj7) * Whole regressing outwards ![](/files/FeZLrdM00wYTad7gMYDZ) ### Questions you should know the answer for I strongly recommend you read the papers we have published in the past few years. The following are important questions that are answered in the papers and that are key to understanding the model: * What other methods have previously been used for the SCP regression problem? What was better about them? What was worse about them? * When should you use Dirichlet boundary condition, Periodic BC, or Neumann BC? * What is the case where Periodic BC can not be used in Flame? * Advantages of the diffuse interface over sharp interface; * Disadvantages of diffuse interface; * What sets phase-field apart from other diffuse interface methods? * Does phase-field need boundary conditions? Where and why? * How does the phase-field interface length scale affect the solution for the eta and phi fields? * How are the chemical potentials defined in Flame formulation? * Why do we need a Laser field? * What is the relationship between mesh refinement and interface length? * Why does the model use a surrogate fluid and stand-in fluid? * What AP/HTPB elastic physical phenomena are not currently captured by the model? * What thermal effects are not currently captured by the model? * What are the key causes of instability? --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://wiki.solids.group/research-practices/student-research-guide.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.