- May 19, 2022
-
-
- Mar 11, 2022
-
-
kar authored
-
- Feb 25, 2022
-
-
kar authored
-
- Jan 05, 2022
-
-
- Oct 07, 2021
-
-
Nico Castro-Folker authored
-
- Jul 12, 2021
-
-
- Jan 11, 2021
-
-
Donovan Allum authored
-
Nico Castro-Folker authored
Added declarations for two functions: one that computes Q (the second invariant of grad(u,v,w)), and one that computes the R (the third invariant of grad(u,v,w)).
-
- Apr 02, 2019
-
-
David Deepwell authored
Vortex stretching is one of the dominant terms in both the vorticity equation and enstrophy equation. They also help in understanding the vortex dynamics and how energy at large scales cascades into small scales. The three components of vortex stretching (omega dot grad) u and the enstrophy stretching production (omega_i omega_j S_ij) are now included and can be computed with the derivatives case file. Files for vortex stretching terms are called vort-stretch<dim> where <dim> is one of x,y,z. The enstrophy stretching production file is called enst-stretch. As these quantities are the product of velocity gradients, care must be made to ensure adequate resolution is present. Update version to 2.0.3
-
- Jul 05, 2018
-
-
Benjamin Storer authored
=== Science === The directory Science/ now contains files corresponding to the various functions in the now-removed Science.cpp. Filenames correspond directly with the function name, and each file contains only one functions, with a few notable exceptions. - Science/get_quads.cpp contains get_quads_x, get_quads_y, and get_quads_z - Science/compute_background_PE contains the helper function compare_pairs The global variables _quadw_x, _quadw_y, and _quadw_z are declared as extern in Science.hpp and declared in Science/compute_quadweights.cpp === Makefile === The Makefile has been modified accordingly. It now automatically detects all Science/*.cpp files and includes them in the compile recipe. The Makefile has also been tidied up a little bit by defining a variable SPINS_BASE which points to the core files.
-
- Mar 22, 2018
-
-
David Deepwell authored
The energy transfer rate from internal energy to BPE is generalized to handle both mapped, and unmapped cases. What had been there was in fact correct for both, though it wasn't realized at first. Archived old wave_reader cases. Minor fixes in other case files.
-
- Jan 30, 2018
-
-
David Deepwell authored
-
- Jan 28, 2018
-
-
David Deepwell authored
The stress along the bottom and top surfaces are calculated and written to a file (stresses_(top/bottom).txt) using the function stresses_top and stresses_bottom in BaseCase. These functions are especially useful with mapped cases.
-
- Jan 10, 2018
-
-
David Deepwell authored
-
- Nov 02, 2017
-
-
David Deepwell authored
The dimensional rho option should not be after the mapping options since the mapping options will need to be specified for an unmapped dimensional density case. This now makes the optional argument ordering more logical.
-
- Oct 24, 2017
-
-
David Deepwell authored
This is the last energy conversion term to get a complete energy budget.
-
- Oct 18, 2017
-
-
David Deepwell authored
-
- Oct 04, 2017
-
-
David Deepwell authored
-
- Aug 25, 2017
-
-
David Deepwell authored
The BPE calculation had assumed that the density field was non-dimensionalized as the density anomaly. An optional argument allows the user to set the density field as dimensional.
-
- Aug 04, 2017
-
-
David Deepwell authored
The mapping affects how to spead voxels out at a given depth. A sorted hill makes loops easier, and thus the calculation of the surface area for a given voxel that intersect the hill.
-
- May 05, 2017
-
-
David Deepwell authored
The background Potential Energy (BPE) is calculated in compute_Background_PE in Science.cpp. The APE can be calculated afterwards from the BPE and PE from the diagnostic file.
-
- Apr 25, 2017
-
-
David Deepwell authored
A new case file, derivatives.cpp, gives a means to compute derivatives of any field or to compute vorticity components. The vorticity calculation in Science is completely re-written so-as to also work for mapped grids. The derivatives file is built to compute secondary variables after a run has already been completed. This uses spins' built-in derivative toolkit allowing multiple variables to be calculated in parallel. A derivative field (one that is the derivative of another) is denoted by an underscore followed by the direction the derivative was taken in (ie. u_x is the x derivative of u).
-
- Mar 05, 2017
-
-
David Deepwell authored
A new case file, derivatives.cpp, gives a means to compute derivatives of any field or to compute vorticity components. The vorticity calculation in Science is completely re-written so-as to also work for mapped grids. The derivatives file is built to compute secondary variables after a run has already been completed. This uses spins' built-in derivative toolkit allowing multiple variables to be calculated in parallel. A derivative field (one that is the derivative of another) is denoted by an underscore followed by the direction the derivative was taken in (ie. u_x is the x derivative of u).
-
- Dec 15, 2015
-
-
Ben Storer authored
- Added 1D and 2D outputs - Added parallel writing and reading
-
- Jul 30, 2012
-
-
Christopher Subich authored
From a version of this code that was floating around, added read_2d_restart to Science.[ch]pp; this reads a 2D array from disk that was previously written by a SPINS job and extends it along the y-dimension to fill the given array; this is useful for extending 2D runs to 3D.
-
Christopher Subich authored
This is the initial commit of SPINS to a git repository, coming from an essentially unmanaged environment. While this is a *complete* archive, this is probably not the most useful form for development going forward. Notably, the future management should be: 1) Pare down the case files 2) Establish branches for individual users. Not as a long-term goal, but instead to keep user-specific case files from lingering in the main repository long after their use is obsolete. 2b) Establish semipermanent branches for typical users. A release branch should include the basic documentation cases, a benchmark case should include benchmarking cases, and there are probably others that aren't coming to mind now. 3) Add helpful MATLAB processing scripts to the repository. Too much of that is ad-hoc now, completely unmanaged. 4) For papers/etc, establish tagged versions.
-