| home | user guide | examples | reference | changelog | resources |
A tube for moving solutions around. Tubes are generally implemented as having negligible volume, so whatever is applied at one end immediately appears at the other. They are also normally uni-directional, as though they contained one-way valves, but this depends on the application.
Control parameters for stellar evolution, setting convergence criteria, governing timestep control, and output options. The function of each variable can be displayed as a tool tip by letting the mouse linger over the variable. _STARTFIELDS _FIELD(erhsFull, threshold on equation errors for applying full corrections in relaxation solution) _FIELD(logEps, log 10 of convergence tolerance) _FIELD(delta, desired average fractional change in variables per step) _FIELD(nitx, max number of iterations before restarting with a smaller step) _FIELD(nRestart, number of successive timestep reductions before giving up) _FIELD(scalePow, when the error is larger than erhsFull the corrections applied are scaled by (err / erhsFull) ^ scalePow) _FIELD(nitCapDt, if a step takes more than nitCapDt iterations to converge the timestep is not increased even if the actual changes are smaller than delta) _FIELD(fDtMax, maximum increase in dt allowed on a single step) _FIELD(showTiming, print profiling information to the terminal) _ENDFIELDS
Adjustment factors for implementing pseudo-stars in which certain physical constants have different values. The factors currently accessible are: the gravitational constant, the energy released by movement in a gravitational field, the energy released in nuclear reactions, the opacity, coulomb interactions, pressure ionization terms and the neutrino luminosity. Three additional terms, not normally present allow for the insertion of a point mass at the center of the star, the application of an external heat bath and the introduction of a bulk, non-specific energy loss term. Each pseudo-stellar model has an associated set of factors, and only makes sense in conjunction with those factors. That is, the model only constitutes a quasi-equilibrium solution of the stellar structure equations when the factors are applied. Typically, pseudo-evolution involves specifying a target set of factors, and gradually modifying the current ones towards the target, letting the model relax at each step.
Stellar evolution based on the code by Peter Eggleton (MNRAS, 1971, ...) with additional parameters for making pseudo-stars in which various physical constants have different values. The problem of computing stellar evolution and examining the models produced has been broken down into a set of components each of which encapsulates a distinct task, such as storing the internal state of a star, or a way if displaying it, or a whole sequence of models. Most objects live in list, and each list holds only one type of object. When an object needs to refer to an object of a different type, it normally gets a reference to the list which contains possible target objects and the user can pick the one to be used. This means that you can have multiple instances of almost any object. The objects specific to stars are: _REFCLASS(StarDataTables) _REFCLASS(StarModel) _REFCLASS(StarView) _REFCLASS(StarModelSequence) _REFCLASS(HRDiagram) _REFCLASS(StarCtrl) _REFCLASS(PseudoPhysFactors) There are two user interface components with those - _CMLINK(star, StarViewEditor, StarViewEditor) and _CMLINK(star, HRDiagramEditor, HRDiagramEditor). A number of standard components can also be used in conjunction with these, including _CMLINK(standard, ColorTable, color tables) and _CMLINK(env, AppletConfig, compound applets). Each component has documentation explaining its own variables and mode of operation (click the ? button in the top right when viewing a component). On startup, various components are loaded automatically for stellar evolution - opacity tables for 2 % metalicity, and a one solar mass initial model (to avoid this, see the _GLOBALGUIDE(star, StarTutorial, star tutorial). To get started quickly, use the following steps to create an evolutionary sequence: _STARTNL _SBS(Start the stellar evolution version of Catacomb as usual) Various windows will appear, including a display of this page. _SBS( ` In the _TT(StarModeSequence) window, click initialize ') It may take a few seconds, reading the data tables, but will then say initialized successfully in the message area near the bottom. _SBS( ` Click run ') to start the calculation running. The step number is displayed in the message area. _SBS( ` In the _TT(HRDiagram) menu, select edit '). This will open a window to display the current HRDiagram. _SBS( ` In the window labelled HRDiagram , click the mouse on the graph and then press f on the keyboard'). This is one of the many ways to change the ranges of the graphs so as to examine the data. Some of the others include left clicking to zoom in, right-clicking to zoom out, press and drag to pan, clicking to the left or below the axes to change just one axis, using the menu at the top right, or typing h and using the resulting window to set things by hand. _SBS(Click with the right mouse button near the middle a couple of times) to center the data. _SBS( ` Click a point in the HRDiagram window') to display properties of the corresponding model. _SBS(Select edit under the _TT(starView) menu). A new window will open for showing the internal structure of the latest model, or of any model you click on in the HR diagram. Complete structures are only available for models marked with fat dots. The _TT(X) and _TT(Y) menus select what is plotted against what. _ENDNL There are many more facilities available - browse the documentation listed above or just try things out.
A stellar model with optional adjustments of certain physical constants using a _CMLINK(star,PseudoPhysFactors, PseudoPhysFactors) object. A model can be created in two stages: construction of the global variables, such as the mixing length to use and mesh spacing function; then construction of an internal state consistent with these parameters. Although, in principle, the latter can be done by a shooting method using the stellar structure equations, the present implementation only allows structures to be imported wholesale, or constructed from other models by relaxation. At the first level, as when creating a new model, you can specify a file from which to read the internal structure in the _TT(modelFile) field. Click read structure to import the structure, making the model available for use in calculations. The idea behind this, is that, for compatibility with other software, the model structure should be written in a standard format. However, Catacomb reads and writes a more verbose XML-like format in which it would be redundant to save all the data a second time. Therefore, the star object, and its XML equivalent only includes the name of the file from which the real structure can be read. Besides the internal structure, various global variables can be specified here. The mixing length parameter is _TT(alpha), the convective diffusion approximation _TT(rcd), and _TT(rmg), _TT(rml) set mass gain or loss rates. All expressions and units are as described by Eggleton (1971). The mesh spacing is governed by a set of ten quantities, _TT(ct1) to _TT(ct10) which are not normally accessible. To modify them, first set the _TT(displayLevel) in the preferences component to 6 or more, then reopen the star model window.
Physical data tables for stellar evolution, including opacities, reaction rates and neutrino generation rates. The data itself is not publicly accessible. Instead the _TT(sourceFile) field specifies a file from which it can be loaded. That is, when saved, the object only keeps the location of the data. The format is the same as is used by the Fortran version of Eggleton's code, with ten floats per line each occupying eight characters. There are no delimiters although non-negative values do begin with a space.