text:
# Acceleration Due To Gravity Formula

## Definition

Any object placed in the field of the gravitational pull of the Earth experiences the gravitational force. Acceleration due to gravity is defined as the acceleration gained by an object because of the force of gravity acting on it. It is represented by ‘g’ and is measured in terms of m/s2. Acceleration due to gravity is a vector quantity, that is, it possesses both magnitude as well as direction.

### Formula

The acceleration due to gravity acting on any object can be given using the following equation:

$g= \frac{GM}{(r+h)^{2}}$

Here, G is the universal gravitational constant whose value is fixed and is equal to 6.673 × 10-11 N.m2/Kg2. M is the mass of the body whose gravitational pull is acting on the object under consideration, r is the radius of the planet and h is the height of the object from the surface of the body.

When the object is on or near the surface of the body, the force of gravity acting on the object is almost constant and the following equation can be used.

$g= \frac{GM}{r^{2}}$

#### Derivation

From the Newton’s Second Law of Motion, we can write

F=ma

Here, F is the force acting on the object, m is its mass and ‘a’ is the acceleration.

Also, as per Newton’s Law of Gravity, we can write,

$F_{g}=\frac{GM_{m}}{(r+h)^{2}}$

It is the gravitational force acting between two bodies lying in the gravitational field of each other. This force acts inwards and is attractive in nature. Each of the two bodies experience the same force directed towards the other.

Using the Newton’s second law of motion, in order to find the acceleration of the body under this condition,

$a=\frac{F_{g}}{m}$

Here, m is the mass of the object for which the acceleration due to gravity is to be calculated.

$a=g=\frac{GM_{m}}{(y+h)^{2}m}$

$g=\frac{GM}{(y+h)^{2}}$

Also, when the object is on or near to the surface the value of g becomes constant and does not change considerably with the height. Hence, we can write,

$g=\frac{gM}{r^{2}}$

#### Solved Examples

Example 1: Given the mass and the diameter of the moon is $7.35\times 10^{22}$ kg and $3.48\times 10^{6}$ m respectively, compute the acceleration due to gravity for an object placed at its surface.

Solution:

As given in the question, the diameter of the moon = $3.48\times 10^{6}$ m

r = diameter/2 = 3.48 × 106 /2 = 1.74 × 106m = 1740000 m

Also, the mass of moon = 7.35 × 1022 kg

Using the formula for acceleration due to gravity, we write,

$g=\frac{gM}{r^{2}}$

Upon substituting the values, we get,

$g= \frac{(6.673\times 10^{-11})(7.35\times 10^{22})}{1740000}$

g=1.620 m/sec2

The acceleration due to gravity is calculated to be 1.620 m/sec2.

Example 2: Given that the mass and the radius of the earth are 5.98x 1024 kg and 6.38 x 106 m respectively. A satellite orbits the earth at a distance of 250 km above the surface. Calculate the acceleration due to gravity experienced by the satellite.

Solution:

It can be seen that, the satellite is present at a considerable height from the surface of the Earth, hence the height cannot be neglected. Using the first formula, we can write,

$R=r+h=(6.38\times 10^{6}m)+(250 km)$

= 6380 km + 250 km = 6630 km = 6,630,000 m

Using the formula for acceleration due to gravity, we write,

$g= \frac{GM}{(y+h)^{2}}$

Upon substituting the values, we get,

$g=\frac{(6.673\times 10^{-11})(5.98\times 10^{24})}{6630000^{2}}$

g=9.07 m/sec2


text:
# Kepler’s law

## Kepler and Tycho Brahe

There is an astronomer who must be mentioned before talking about Kepler (Johannes Kepler 1571 ~ 1630). That's Tycho Brahe.
Tycho Brahe (1546-1601) is a famous Danish astronomer. With the development of astronomical equipment, he left a vast amount of information about the location of the stars and he made a great contribution to the development of astronomy.

When Brahe died, Kepler was asked to organize observational data accumulated for 16 years. Based on these data, he published Kepler's first and second laws in 1609.
Kepler's law is known to have contributed greatly to establishing Newton's laws of mechanics. Newton is said to have been deeply impressed with Kepler's law.
In other words, Kepler's law has made a great progress in physics as well as astronomy.

## First law of Kepler (Law of orbits)

The orbit of every planet is an ellipse with the Sun at one of the two foci.

## Second law of Kepler

A line joining a planet and the Sun sweeps out equal areas during equal intervals of time.

## Third law of Kepler

The square of the orbital period of a planet is directly proportional to the cube of the semi-major axis of its orbit.

$(orbital\,period(P))^{2} ∝ (semi-major\,axis(a))^{3}$

format: plain


text:
# Wave functions and Schrödinger equation

Exploring Quantum Physics – Week 1 Lecture 1

## Early Experiments

• Photo electric effect: beam of light hitting charged plates with a potential across them creates current.
• Expected: amount of current is independent of frequency of the light, dependent on the intensity.
• Actual: current depends on frequency of light (no current below frequency threshold), independent of intensity.
• Einstein proposed photons (nobel prize)
• Electron diffraction: (Davisson-Germer experiment)
• Crystalline structure acts as a diffraction grating, electron beam demonstrates wave interference like light.
• Experiment supports DeBroglie hypothesis:
$\lambda = h / p$, $E = \frac{hc}{\lambda} = \hbar \omega$
• For a derivation of the DeBroglie wave length, see
http://www.chip-architect.com/physics/deBroglie.pdf

## Wave Equation

Wave equation:
$\displaystyle \begin{array}{ll} u(x, t) &= A_0 \sin(kx - \omega t + \phi_0) \\ &= A_0 \Im e^{i(kx - \omega t + \phi_0)} \end{array}$
Where k is the wave number

$\displaystyle \lambda = \frac{2 \pi}{k} \qquad \omega = c k$
Where c is the wave velocity

We can represent particles as a wave (but not the other way around) via the Fourier transform:

$\displaystyle f(x) = \int dk A_k e^{ikx}$
Where $A_k$ is the “fourier harmonics” (amplitudes)

Represent a particle as a Gaussian wave with a sharp peak:

Particle as a Gaussian wave.

## The Schrödinger wave equation

$\displaystyle \Psi(x,t) = C e^{i(kx - \omega t)}$
Where $\Psi$ is the wave function, and $C$ is the constant of proportionality, ignore for now.

Since $p = \hbar k$ and $E = \hbar \omega$, can write as:
$\displaystyle \Psi(x,t) = C e^{\frac{i}{\hbar}(px - Et)}$

Taking the derivative:
$\displaystyle \frac{\partial}{\partial t} \Psi = \frac{-i}{\hbar} E \Psi \qquad \frac{\partial}{\partial x} \Psi = \frac{-i}{\hbar} p \Psi$
(or for a momentum vector: $\nabla \Psi = \frac{i}{\hbar} \vec{p} \Psi$)

For a free particle (not in a potential field), $E = \mathrm{k.e.} = \frac{mv^2}{2} = \frac{p^2}{2m}$, so:
$\displaystyle E \Psi = i \hbar \frac{\partial}{\partial t} \Psi = \frac{\vec{p}^2}{2m} \Psi = \frac{(-i \hbar \nabla)^2}{2m} \Psi = \frac{\hbar^2 \nabla^2}{2m} \Psi$

Giving the free schrödinger equation:

$\displaystyle \left[ i \hbar \frac{\partial}{\partial t} + \frac{\hbar^2 \nabla^2}{2m} \right] \Psi(\vec{r}, t) = 0$

$\displaystyle \hat{H} = \mathrm{Hamiltonian} = \mathrm{K.E.} + \mathrm{Potential} = \frac{\vec{p}^2}{2m} + V(\vec{r})$

Using the Hamiltonian for energy gives the fundamental equation of quantum physics:

$\displaystyle i \hbar \frac{\partial \Psi}{\partial t} = \hat{H} \Psi$

## Particle delocalization

Take a Gaussian wave-packet $\Psi(x, 0) = A e^{-x^2 / 2d^2}$
Solve schrödinger with this gives
$\displaystyle \left| \Psi(x,t) \right|^2 \propto \exp \left[ -\frac{x^2}{d^2 (1+t^2/\tau^2)} \right]$
where $\tau = md^2 / \hbar =$ delocalization time

$\displaystyle \Psi(x, 0) = Ae^{-\frac{x^2}{2d^2}} = \int \frac{dp}{h} \phi_p e^{\frac{i}{\hbar} px}$

Recognize the Gaussian integral: $\int_{-\infty}^\infty e^{-\alpha x^2 + \beta x} dx = \sqrt{\frac{\pi}{\alpha}} e^{\frac{\beta^2}{4\alpha}}$

Gives wave-function in momentum space:
$\phi_p = \int dx \Psi(x, 0)e^{-\frac{i}{\hbar}px} \propto e^{\frac{p^2d^2}{2\hbar^2}}$

Notice the uncertainty $\delta x \sim d$, but $\delta p \sim \hbar / d$. This is a manifestation of the Heisenberg uncertainty principle:
$\displaystyle \delta x \cdot \delta p \geq \hbar$


text:
# How do you solve the system 7x + 2y = 2 and 6x - 2y = 8?

May 16, 2015

I notice that all the terms in the second equation are divisible by 2 and it will be easy to isolate $y$, so let's do that first.

$6 x - 2 y = 8$

Divide both sides by 2 to get

$3 x - y = 4$

Add $y$ to both sides to get

$3 x = 4 + y$

Subtract 8 from both sides to get

$y = 3 x - 4$

Now substitute this expression for $y$ into the first equation...

$2 = 7 x + 2 y$

$= 7 x + 2 \left(3 x - 4\right)$

$= 7 x + 6 x - 8$

$= 13 x - 8$

Add 8 to both sides to get

$13 x = 10$

Divide both sides by 13 to get

$x = \frac{10}{13}$

$y = 3 x - 4 = \frac{3 \times 10}{13} - 4$

$= \frac{30}{13} - \frac{4 \times 13}{13}$

$= \frac{30 - 52}{13}$

$= - \frac{22}{13}$


text:
# 113 (number)

(Redirected from One hundred thirteen)
 ← 112 113 114 →
Cardinalone hundred thirteen
Ordinal113th
(one hundred thirteenth)
Factorizationprime
Prime30th
Divisors1, 113
Greek numeralΡΙΓ´
Roman numeralCXIII
Binary11100012
Ternary110123
Octal1618
Duodecimal9512

113 (one hundred [and] thirteen) is the natural number following 112 and preceding 114.

113 is:

## Other uses

• 113 (band), a French hip hop group
• 113, the port number of the IDENT Internet protocol that helps identify the user of a particular TCP connection
• 113, in enduro, is regarded as an unlucky number to be given to a race entrant and is colloquially known as a "blind pew"


text:
# On a Cohen–Lenstra heuristic for Jacobians of random graphs

```@article{Clancy2014OnAC,
title={On a Cohen–Lenstra heuristic for Jacobians of random graphs},
author={J. Clancy and N. Kaplan and Timothy Leake and S. Payne and M. Wood},
journal={Journal of Algebraic Combinatorics},
year={2014},
volume={42},
pages={701-723}
}```
• J. Clancy, +2 authors M. Wood
• Published 2014
• Mathematics
• Journal of Algebraic Combinatorics
• In this paper, we make specific conjectures about the distribution of Jacobians of random graphs with their canonical duality pairings. Our conjectures are based on a Cohen–Lenstra-type heuristic saying that a finite abelian group with duality pairing appears with frequency inversely proportional to the size of the group times the size of the group of automorphisms that preserve the pairing. We conjecture that the Jacobian of a random graph is cyclic with probability a little over .7935. We… CONTINUE READING
32 Citations

#### References

SHOWING 1-10 OF 30 REFERENCES


text:
# Watched Khan Academy, now I’m confused by division (noncommutative) being the inverse of multiplication (commutative)

I was watching a khan academy video about division which described division in two different ways and I’m now confused by my interpretation of division as the inverse of multiplication.

I understand why multiplication is commutative: 12 objects could be counted as 3 sets of 4 or counted as 4 sets of 3 with the same result:

My interpretation of how 3x4=12 AND 4x3=12  However, when he introduced division he asked ‘what is 8÷2?’, and said it was the answer to the question ‘how many groups of two can be made out of eight?’, and he drew:

4 groups of 2 could be made, so the answer is 4.  But, he then immediately said ‘Or it’s like the answer to the question - split 8 into 2 equal groups, how many are in each group?’, and he drew:

4 objects were in each group, so the answer is 4.

I was confused to see two different ways to model division, since there’s only one way to write it.

With multiplication there are two ways to write the expression, and they correspond to two ways to model the situation - and it all demonstrates the commutative nature of multiplication.

Thinking of division as the inverse of multiplication, it’s like the two models of division are recovering the two models of multiplication and it all fits together - the commutativity of multiplication is still ‘in’ division somewhere. However, whereas multiplication has notation for its two commutations, it seems like there’s a discrepancy with the division notation. It’s like there’s information lost somewhere.

It feels like division wants commutativity, it just doesn’t know how.

Q1: What have I misunderstood, how can the same notation ‘a÷b’ describe two different processes?

Q2: Does mathematics talk about information being lost by having something which is noncommutative as the inverse of something which is commutative?

Q3: What area(s) of mathematics have I touched on/where can I go for more information?

Thanks so much for your time!

There is no "information being lost" here. The fact that division describes the result of two different processes actually corresponds directly to the first fact you mentioned: two different processes give the same result under multiplication. To put it another way, the two different processes describing division come from commutativity of multiplication, not some "missing" commutativity of division.

When you ask "what is $$8$$ divided by $$2$$?", you are asking "what number, when multiplied by $$2$$, gives $$8$$?" That is, $$8 \div 2 = \mathord{?}$$ means the same thing as $$8 = \mathord{?} \times 2$$, i.e., how many groups of size $$2$$ do you need to make $$8$$? The answer is $$8\div 2 = 4$$, because $$4\times 2 = 8$$, i.e., $$4$$ groups of $$2$$ make $$8$$.

But we also know that $$\mathord{?}\times 2 = 2\times \mathord{?}$$. If we take some number $$\mathord{?}$$ of groups of size $$2$$, we'll have the same number of things as if we take $$2$$ groups of that same size $$\mathord{?}$$.

So we could equally well say that $$8 \div 2 = \mathord{?}$$ means the same thing as $$8 = 2\times \mathord{?}$$, i.e., $$2$$ groups of what size make $$8$$? The answer is $$8\div 2 = 4$$, because $$2\times 4 = 8$$, i.e., $$2$$ groups of $$4$$ make $$8$$.

I will address $$Q1$$. I don't think I know the answer for the other two questions. The simbol $$a \div b$$ denotes a number and this same number is obtained in the two procedures you described. If you wish to be more simbolic we can denote the first division by $$a \div b$$ and the second one by $$a \div' b$$. Let's show that this two numbers are the same. Notice that by your definition of multiplication we have $$a=b(a \div b) = b(a \div' b)$$ and by associativity we conclude that $$b\big((a \div b)-(a \div' b)\big) = b(a \div' b) - b(a \div b) =0.$$ Therefore, we have: $$b\big((a \div b)-(a \div' b)\big)=0.$$

Now, $$b \neq 0$$ and therefore the only way for us to obtain a $$0$$ in the above identity is if
$$(a \div b)-(a \div' b)=0.$$

From that we obtain $$a \div b = a \div' b.$$

So, the two procedures give you the same number.


text:
FoCM 2014 conference

Plenary talk

December 19, 11:00 ~ 11:55

## Solving high-dimensional PDEs by tensor product approximation

### TU Berlin , Germany   -   schneidr@math.tu-berlin.de

Hierarchical Tucker tensor format introduced by Hackbusch et al. including Tensor Trains (TT) (Tyrtyshnikov) have been introduced in 2009. These representations offer stable and robust approximation of high order tensors and multi-variate functions by a low order cost . For many high dimensional problems, including many body quantum mechanics, uncertainty quantification etc., this approach has great potential to circumvent from the {\em curse of dimensionality}. In case $\mathcal{V} = \bigotimes_{i=1}^d \mathcal{V}_i$ the complexity remains proportional to $d$ and polynomial in some multilinear ranks. The approximation properties w.r.t. to these ranks are depending on bilinear approximation rates and corresponding trace class norms. Despite fundamental problems in multilinear approximation, under certain conditions optimal convergence rates could be shown. The present formats are equivalent to tree tensor networks states and matrix product states (MPS) introduced for the treatment of quantum spin systems. For numerical computations, we cast the PDEs into optimization problems constraint by restricting to set of d tensors of bounded multilinear ranks $\mathbf{r}$. The underlying admissible set is no longer convex, but it is an algebraic variety. We consider optimization on Riemannian manifold and corresponding gradient schemes. Numerical examples include electronic Schrödinger equations, uncertainty quantification and molecular dynamics.

Joint work with A. Uschmajew (U Bonn).


text:
SKY-MAP.ORG
 Home Getting Started To Survive in the Universe News@Sky Astro Photo The Collection Forum Blog New! FAQ Press Login

# ε Sgr (Kaus Australis)

Contents

### Images

DSS Images   Other Images

### Related articles

 Early Infrared Spectral Development of V1187 Scorpii (Nova Scorpii 2004 No. 2)We report on an unprecedented infrared time series of spectra of V1187Sco, a very fast ONeMg nova. The observations covered a 56 day period(2004 August 6-September 30) starting 2 days after the nova's peakbrightness. Time evolution of the spectra revealed changing linestrengths and profiles on timescales of less than a day to weeks as thenova evolved from early postmaximum to early coronal phases. When ourground-based optical and Spitzer Space Telescope data were combined, thewavelength coverage of 0.38-36 μm allowed an accurate spectral energydistribution to be derived when it was about 6 weeks after outburst.Developing double structure in the He I lines showed them changing fromnarrow to broad in only a few days. Using the O I lines in combinationwith the optical spectra, we derived a reddening of E(B-V)=1.56+/-0.08and a distance of 4.9+/-0.5 kpc. Modeling of the ejected materialstrongly suggested that it was geometrically thick withΔR/R=0.8-0.9 (more of a wind than a shell) and a low fillingfactor of order a few percent. The line shapes were consistent with acylindrical jet, bipolar, or spherical Hubble flow expansion with amaximum speed of about -3000 km s-1. The central peakappeared to be more associated with the spherical component, while thetwo peaks (especially in Hβ) suggested a ring with either a lowervelocity component or with its axis inclined to the line of sight. Computed Hβ indices from ATLAS9 model atmospheresAims.Grids of Hβ indices based on updated (new-ODF) ATLAS9 modelatmospheres were computed for solar and scaled solar metallicities[+0.5], [+0.2], [0.0], [ -0.5] , [ -1.0] , [ -1.5] , [ -2.0] , [ -2.5]and for α enhanced compositions [+0.5a], [0.0a], [ -0.5a] , [-1.0a] , [ -1.5a] , [ -2.0a] , [ -2.5a] , and [ -4.0a] . Methods:.Indices for T_eff > 5000 K were computed with the same methods asdescribed by Lester et al. (1986, LGK86) except for a differentnormalization of the computed natural system to the standard system.LGK86 used special ODFs to compute the fluxes. For T_eff ≤ 5000 K wecomputed the fluxes using the synthetic spectrum method. In order toassess the accuracy of the computed indices comparisons were made withthe indices computed by Smalley & Dworetsky (1995, A&A, 293,446, MD95) and with the empirical relations T_eff-Hβ given byAlonso et al. (1996, A&A, 313, 873) for several metallicities.Furthermore, for cool stars, temperatures inferred from the computedindices were compared with those of the fundamental stars listed byMD95. The same kind of comparison was made between gravities for B-typestars. Results: .The temperatures from the computed indices are ingood agreement, within the error limits, with the literature values for4750 K ≤ T_eff ≤ 8000 K, while the gravities agree for T_eff> 9000 K. The computed Hβ indices for the Sun and for Procyonare very close to the observed values. The comparison between theobserved and computed Hβ indices as function of the observedHβ has shown a very small trend which almost completely disappearswhen only stars hotter than 10 000 K are considered. The trend due tothe cool stars is probably related with the low accuracy of thefundamental T_eff which are affected by large errors for most of thestars. Atlas and Catalog of Dark Clouds Based on Digitized Sky Survey IWe present a quantitative atlas and catalog of dark clouds derived byusing the optical database Digitized Sky Survey I''. Applying atraditional star-count technique to 1043 plates contained in thedatabase, we produced an AV map covering the entire region inthe galactic latitude range |b| ≤ 40°. The map was drawn at twodifferent angular resolutions of 6' and 18', and is shown in detail in aseries of figures in this paper. Based on the AV map, weidentified 2448 dark clouds and 2841 clumps located inside them. Somephysical parameters, such as the position, extent, and opticalextinction, were measured for each of the clouds and clumps. We alsosearched for counterparts among already known dark clouds in theliterature. The catalog of dark clouds presented in this paper lists thecloud parameters as well as the counterparts. Deepsky delights.Not Available Variability of Stars in the Pulkovo Spectrophotometric CatalogWe present the results of a statistical study of brightness variabilityfor 693 stars of the Pulkovo spectrophotometric database in fivespectral bands in the range λλ 320 1080 nm. Significantbrightness variations were detected in at least one spectral bandagainst the background of the random noise for one-third of the starsnot earlier believed to be variable. A comparison of the distributionsof these variations in amplitude and spectral band for the normal andvariable stars shows that variability is inherent to most stars to someextent and is often wavelength dependent. First results from the ESO VLTI calibrators programThe ESO Very Large Telescope Interferometer (VLTI) is one of the leadinginterferometric facilities. It is equipped with several 8.2 and 1.8 mtelescopes, a large number of baselines up to 200 m, and with severalsubsystems designed to enable high quality measurements and to improvesignificantly the limits of sensitivities currently available tolong-baseline interferometry. The full scientific potential of the VLTIcan be exploited only if a consistent set of good quality calibrators isavailable. For this, a large number of observations of potentialcalibrators have been obtained during the commissioning phase of theVLTI. These data are publicly available. We briefly describe theinterferometer, the VINCI instrument used for the observations, the dataflow from acquisition to processed results, and we present and commenton the volume of observations gathered and scrutinized. The result is alist of 191 calibrator candidates, for which a total of 12 066observations can be deemed of satisfactory quality. We present a generalstatistical analysis of this sample, using as a starting point theangular diameters previously available in the literature. We derive thegeneral characteristics of the VLTI transfer function, and its trendwith time in the period 2001 through mid-2004. A second paper will bedevoted to a detailed investigation of a selected sample, aimed atestablishing a VLTI-based homogeneous system of calibrators. CHARM2: An updated Catalog of High Angular Resolution MeasurementsWe present an update of the Catalog of High Angular ResolutionMeasurements (CHARM, Richichi & Percheron \cite{CHARM}, A&A,386, 492), which includes results available until July 2004. CHARM2 is acompilation of direct measurements by high angular resolution methods,as well as indirect estimates of stellar diameters. Its main goal is toprovide a reference list of sources which can be used for calibrationand verification observations with long-baseline optical and near-IRinterferometers. Single and binary stars are included, as are complexobjects from circumstellar shells to extragalactic sources. The presentupdate provides an increase of almost a factor of two over the previousedition. Additionally, it includes several corrections and improvements,as well as a cross-check with the valuable public release observationsof the ESO Very Large Telescope Interferometer (VLTI). A total of 8231entries for 3238 unique sources are now present in CHARM2. Thisrepresents an increase of a factor of 3.4 and 2.0, respectively, overthe contents of the previous version of CHARM.The catalog is only available in electronic form at the CDS viaanonymous ftp to cdsarc.u-strasbg.fr (130.79.128.5) or via http://cdsweb.u-strasbg.fr/cgi-bin/qcat?J/A+A/431/773 The physical properties of normal A starsDesignating a star as of A-type is a result of spectral classification.After separating the peculiar stars from those deemed to be normal usingthe results of a century of stellar astrophysical wisdom, I define thephysical properties of the "normal" stars. The hotter A stars haveatmospheres almost in radiative equilibrium. In the A stars convectivemotions can be found which increase in strength as the temperaturedecreases. Classification of Spectra from the Infrared Space Observatory PHT-S DatabaseWe have classified over 1500 infrared spectra obtained with the PHT-Sspectrometer aboard the Infrared Space Observatory according to thesystem developed for the Short Wavelength Spectrometer (SWS) spectra byKraemer et al. The majority of these spectra contribute to subclassesthat are either underrepresented in the SWS spectral database or containsources that are too faint, such as M dwarfs, to have been observed byeither the SWS or the Infrared Astronomical Satellite Low ResolutionSpectrometer. There is strong overall agreement about the chemistry ofobjects observed with both instruments. Discrepancies can usually betraced to the different wavelength ranges and sensitivities of theinstruments. Finally, a large subset of the observations (~=250 spectra)exhibit a featureless, red continuum that is consistent with emissionfrom zodiacal dust and suggest directions for further analysis of thisserendipitous measurement of the zodiacal background.Based on observations with the Infrared Space Observatory (ISO), aEuropean Space Agency (ESA) project with instruments funded by ESAMember States (especially the Principle Investigator countries: France,Germany, Netherlands, and United Kingdom) and with the participation ofthe Institute of Space and Astronautical Science (ISAS) and the NationalAeronautics and Space Administration (NASA). J - K DENIS photometry of a VLTI-selected sample of bright southern starsWe present a photometric survey of bright southern stars carried outusing the DENIS instrument equipped with attenuating filters. Theobservations were carried out not using the survey mode of DENIS, butwith individual target pointings. This project was stimulated by theneed to obtain near-infrared photometry of stars to be used in earlycommissioning observations of the ESO Very Large TelescopeInterferometer, and in particular to establish a network of brightcalibrator sources.We stress that near-infrared photometry is peculiarly lacking for manybright stars. These stars are saturated in 2MASS as well as in regularDENIS observations. The only other observations available for brightinfrared stars are those of the Two Micron Sky Survey dating from overthirty years ago. These were restricted to declinations above≈-30°, and thus cover only about half of the sky accessible fromthe VLTI site.We note that the final 2MASS data release includes photometry of brightstars, obtained by means of point-spread function fitting. However, thismethod only achieves about 30% accuracy, which is not sufficient formost applications.In this work, we present photometry for over 600 stars, each with atleast one and up to eight measurements, in the J and K filters. Typicalaccuracy is at the level of 0\fm05 and 0\fm04 in the J and K_s bands,respectively.Based on observations collected at the European Southern Observatory, LaSilla.Tables 1 and 2 are only available in electronic form at the CDS viaanonymous ftp to cdsarc.u-strasbg.fr (130.79.128.5) or viahttp://cdsweb.u-strasbg.fr/cgi-bin/qcat?J/A+A/413/1037 The magnetic field in the central parsecNot Available 400 years of Uranometria.Not Available The total-to-selective extinction ratio determined from near IR photometry of OB starsThe paper presents an extensive list of the total to selectiveextinction ratios R calculated from the infrared magnitudes of 597 O andB stars using the extrapolation method. The IR magnitudes of these starswere taken from the literature. The IR colour excesses are determinedwith the aid of "artificial standards" - Wegner (1994). The individualand mean values of total to selective extinction ratios R differ in mostcases from the average value R=3.10 +/-0.05 - Wegner (1993) in differentOB associations. The relation between total to selective extinctionratios R determined in this paper and those calculated using the "methodof variable extinction" and the Cardelli et al. (1989) formulae isdiscussed. The R values presented in this paper can be used to determineindividual absolute magnitudes of reddened OB stars with knowntrigonometric parallaxes. The heterogeneous class of lambda Bootis starsWe demonstrate that it is arduous to define the lambda Boo stars as aclass of objects exhibiting uniform abundance peculiarities which wouldbe generated by a mechanism altering the structure of their atmosphericlayers. We collected the stars classified as lambda Boo up to now anddiscuss their properties, in particular the important percentage ofconfirmed binaries producing composite spectra (including our adaptiveoptics observations) and of misclassified objects. The unexplained RVvariables (and thus suspected binaries), the known SB for which we lackinformation on the companion, the stars with an UV flux inconsistentwith their classification, and the fast rotating stars for which noaccurate abundance analysis can be performed, are also reviewed.Partly based on observations collected at the CFH Telescope (Hawaii) andat TBL of the Pic du Midi Observatory (France).Table \ref{tab5} is only available in electronic form athttp://www.edpsciences.org Catalogue of averaged stellar effective magnetic fields. I. Chemically peculiar A and B type starsThis paper presents the catalogue and the method of determination ofaveraged quadratic effective magnetic fields < B_e > for 596 mainsequence and giant stars. The catalogue is based on measurements of thestellar effective (or mean longitudinal) magnetic field strengths B_e,which were compiled from the existing literature.We analysed the properties of 352 chemically peculiar A and B stars inthe catalogue, including Am, ApSi, He-weak, He-rich, HgMn, ApSrCrEu, andall ApSr type stars. We have found that the number distribution of allchemically peculiar (CP) stars vs. averaged magnetic field strength isdescribed by a decreasing exponential function. Relations of this typehold also for stars of all the analysed subclasses of chemicalpeculiarity. The exponential form of the above distribution function canbreak down below about 100 G, the latter value representingapproximately the resolution of our analysis for A type stars.Table A.1 and its references are only available in electronic form atthe CDS via anonymous ftp to cdsarc.u-strasbg.fr (130.79.128.5) or viahttp://cdsweb.u-strasbg.fr/cgi-bin/qcat?J/A+A/407/631 and Tables 3 to 9are only available in electronic form at http://www.edpsciences.org delta Scorpii: Visual Photometric Variability in 2000-2002Not Available Rotational velocities of A-type stars in the northern hemisphere. II. Measurement of v sin iThis work is the second part of the set of measurements of v sin i forA-type stars, begun by Royer et al. (\cite{Ror_02a}). Spectra of 249 B8to F2-type stars brighter than V=7 have been collected at Observatoirede Haute-Provence (OHP). Fourier transforms of several line profiles inthe range 4200-4600 Å are used to derive v sin i from thefrequency of the first zero. Statistical analysis of the sampleindicates that measurement error mainly depends on v sin i and thisrelative error of the rotational velocity is found to be about 5% onaverage. The systematic shift with respect to standard values fromSlettebak et al. (\cite{Slk_75}), previously found in the first paper,is here confirmed. Comparisons with data from the literature agree withour findings: v sin i values from Slettebak et al. are underestimatedand the relation between both scales follows a linear law ensuremath vsin inew = 1.03 v sin iold+7.7. Finally, thesedata are combined with those from the previous paper (Royer et al.\cite{Ror_02a}), together with the catalogue of Abt & Morrell(\cite{AbtMol95}). The resulting sample includes some 2150 stars withhomogenized rotational velocities. Based on observations made atObservatoire de Haute Provence (CNRS), France. Tables \ref{results} and\ref{merging} are only available in electronic form at the CDS viaanonymous ftp to cdsarc.u-strasbg.fr (130.79.125.5) or viahttp://cdsweb.u-strasbg.fr/cgi-bin/qcat?J/A+A/393/897 The determination of Teff for metal-poor A-type stars using V and 2MASS J, H and K magnitudesEffective temperatures (T_eff) can be determined from (V-J)_0, (V-H)_0and (V-K)_0 colours that are derived from 2MASS magnitudes. This givesanother way to estimate the T_eff of faint blue halo stars (V la 15)whose temperatures are now usually deduced from bo.Transformations (adapted from Carpenter \cite{carp01b}) are used tochange colours derived from the 2MASS data to the Johnson system. T_effis then derived from these colours using an updated Kurucz model. Tablesare given to derive T_eff as a function of (V-J)_0, (V-H)_0 and (V-K)_0for a variety of metallicities and log g suitable for blue horizontalbranch and main sequence stars. The temperatures obtained in this wayare compared with those in the recent literature for various stars with5 <= V <= 15 and T_eff in the range 6500 to 9500 K; systematicdifferences are ~ 100 K. An exception is the sample of BHB starsobserved by Wilhelm et al. (\cite{wbsl99}) whose T_eff are significantlycooler than those we derive by an amount that increases with increasingtemperature. NOAO is operated by the Association of Universities forresearch in Astronomy, Inc., under contract with the National ScienceFoundation. Tables 2 and 3 are only available in electronic form at theCDS via anonymous ftp to cdsarc.u-strasbg.fr (130.79.128.5) or via http:/ /cdsweb.u-strasbg.fr/cgi-bin/ qcat?J/ A+A/391/1039 CHARM: A Catalog of High Angular Resolution MeasurementsThe Catalog of High Angular Resolution Measurements (CHARM) includesmost of the measurements obtained by the techniques of lunaroccultations and long-baseline interferometry at visual and infraredwavelengths, which have appeared in the literature or have otherwisebeen made public until mid-2001. A total of 2432 measurements of 1625sources are included, along with extensive auxiliary information. Inparticular, visual and infrared photometry is included for almost allthe sources. This has been partly extracted from currently availablecatalogs, and partly obtained specifically for CHARM. The main aim is toprovide a compilation of sources which could be used as calibrators orfor science verification purposes by the new generation of largeground-based facilities such as the ESO Very Large Interferometer andthe Keck Interferometer. The Catalog is available in electronic form atthe CDS via anonymous ftp to cdsarc.u-strasbg.fr (130.79.128.5) or viahttp://cdsweb.u-strasbg.fr/cgi-bin/qcat?J/A+A/386/492, and from theauthors on CD-Rom. Rotational velocities of A-type stars. I. Measurement of v sin i in the southern hemisphereWithin the scope of a Key Programme determining fundamental parametersof stars observed by HIPPARCOS, spectra of 525 B8 to F2-type starsbrighter than V=8 have been collected at ESO. Fourier transforms ofseveral line profiles in the range 4200-4500 Å are used to derivev sin i from the frequency of the first zero. Statistical analysis ofthe sample indicates that measurement error is a function of v sin i andthis relative error of the rotational velocity is found to be about 6%on average. The results obtained are compared with data from theliterature. There is a systematic shift from standard values from\citet{Slk_75}, which are 10 to 12% lower than our findings. Comparisonswith other independent v sin i values tend to prove that those fromSlettebak et al. are underestimated. This effect is attributed to thepresence of binaries in the standard sample of Slettebak et al., and tothe model atmosphere they used. Based on observations made at theEuropean Southern Observatory (ESO), La Silla, Chile, in the frameworkof the Key Programme 5-004-43K. Table 4 is only available in electronicform at the CDS via anonymous ftp to cdsarc.u-strasbg.fr (130.79.125.5)or via http://cdsweb.u-strasbg.fr/cgi-bin/qcat?J/A+A/381/105 A spectroscopic survey for lambda Bootis stars. II. The observational datalambda Bootis stars comprise only a small number of all A-type stars andare characterized as nonmagnetic, Population i, late B to early F-typedwarfs which show significant underabundances of metals whereas thelight elements (C, N, O and S) are almost normal abundant compared tothe Sun. In the second paper on a spectroscopic survey for lambda Bootisstars, we present the spectral classifications of all program starsobserved. These stars were selected on the basis of their Strömgrenuvbybeta colors as lambda Bootis candidates. In total, 708 objects insix open clusters, the Orion OB1 association and the Galactic field wereclassified. In addition, 9 serendipity non-candidates in the vicinity ofour program stars as well as 15 Guide Star Catalogue stars were observedresulting in a total of 732 classified stars. The 15 objects from theGuide Star Catalogue are part of a program for the classification ofapparent variable stars from the Fine Guidance Sensors of the HubbleSpace Telescope. A grid of 105 MK standard as well as pathological''stars guarantees a precise classification. A comparison of our spectralclassification with the extensive work of Abt & Morrell(\cite{Abt95}) shows no significant differences. The derived types are0.23 +/- 0.09 (rms error per measurement) subclasses later and 0.30 +/-0.08 luminosity classes more luminous than those of Abt & Morrell(\cite{Abt95}) based on a sample of 160 objects in common. The estimatederrors of the means are +/- 0.1 subclasses. The characteristics of oursample are discussed in respect to the distribution on the sky, apparentvisual magnitudes and Strömgren uvbybeta colors. Based onobservations from the Observatoire de Haute-Provence, OsservatorioAstronomico di Padova-Asiago, Observatório do Pico dosDias-LNA/CNPq/MCT, Chews Ridge Observatory (MIRA) and University ofToronto Southern Observatory (Las Campanas). Search for low-mass PMS companions around X-ray selected late B starsWe have observed 49 X-ray-detected bright late B-type dwarfs to searchfor close low-mass pre-main sequence (PMS) companions using the EuropeanSouthern Observatory's ADONIS (Adaptive Optics Near Infrared System)instrument. We announce the discovery of 21 new companions in 9binaries, 5 triple, 4 quadruple system and 1 system consisting of fivestars. The detected new companions have K magnitudes between 6.5m and17.3m and angular separations ranging from 0.12 arcsec to 14.1 arcsec(18-2358 AU). Based on observations obtained at the European SouthernObservatory, La Silla, Chile (ESO programme No.~62.I-0477, and Swiss70~cm photometric telescope). Catalogue of Apparent Diameters and Absolute Radii of Stars (CADARS) - Third edition - Comments and statisticsThe Catalogue, available at the Centre de Données Stellaires deStrasbourg, consists of 13 573 records concerning the results obtainedfrom different methods for 7778 stars, reported in the literature. Thefollowing data are listed for each star: identifications, apparentmagnitude, spectral type, apparent diameter in arcsec, absolute radiusin solar units, method of determination, reference, remarks. Commentsand statistics obtained from CADARS are given. The Catalogue isavailable in electronic form at the CDS via anonymous ftp tocdsarc.u-strasbg.fr (130.79.128.5) or viahttp://cdsweb.u-strasbg.fr/cgi-bin/qcar?J/A+A/367/521 The proper motions of fundamental stars. I. 1535 stars from the Basic FK5A direct combination of the positions given in the HIPPARCOS cataloguewith astrometric ground-based catalogues having epochs later than 1939allows us to obtain new proper motions for the 1535 stars of the BasicFK5. The results are presented as the catalogue Proper Motions ofFundamental Stars (PMFS), Part I. The median precision of the propermotions is 0.5 mas/year for mu alpha cos delta and 0.7mas/year for mu delta . The non-linear motions of thephotocentres of a few hundred astrometric binaries are separated intotheir linear and elliptic motions. Since the PMFS proper motions do notinclude the information given by the proper motions from othercatalogues (HIPPARCOS, FK5, FK6, etc.) this catalogue can be used as anindependent source of the proper motions of the fundamental stars.Catalogue (Table 3) is only available at the CDS via anonymous ftp tocdsarc.u-strasbg.fr (130.79.128.5) or viahttp://cdsweb.u-strastg.fr/cgi-bin/qcat?J/A+A/365/222 A Study of the B-V Color-Temperature RelationWe derive a B-V color-temperature relation for stars in the leastmodel-dependent way employing the best modern data. The fit we obtainedwith the form Teff=Teff{(B-V)0, [Fe/H],logg} covers stars in the range F0-K5 with metallicity [Fe/H]=-1.5 to+0.3 for both dwarfs and giants. The fit is well constrained, and theresidual temperature of the fit is 62 K, which is consistent with whatis expected from the quality of the input data. Metallicity and surfacegravity effects are well separated from the color dependence. Dwarfs andgiants match in a single family of the fit, differing only in logg. Thefit also detects the interstellar extinction for nearby stars with theamount E(B-V)=0.235+/-0.03 mag kpc-1. Taking our newlyobtained relation as a reference, we examine a number of B-Vcolor-temperature relations and atmosphere models available in theliterature. We find with the Kurucz atmosphere a systematic error of0.07 mag in B-V in the color-temperature relation across G-K5 dwarfs. Onthe other hand, the Bell-Gustafsson atmosphere gives colors in agreementwith our empirical relation from F to G stars; for late-K stars,however, it gives colors that are too blue by 0.05 mag. We also arguefor errors in the temperature scale adopted in popularly used stellarpopulation synthesis models; synthetic colors from these models, basedon the temperature calibration of Ridgway et al., may be too blue foraged elliptical galaxies. Finally, we derive the color index of the Sunto be (B-V)solar=0.626+/-0.018 and discuss that redder colors(e.g., 0.65-0.67) often quoted in the literature are incompatible withthe color-temperature relation for normal stars. Empirical Luminosities and Radii of Early-Type Stars after HipparcosUsing Hipparcos parallaxes we derive empirical luminosities and radii ofthe early-type stars for which the effective temperatures are known fromdirectly measured angular diameters and total absolute fluxes. Theempirical luminosities allow a direct comparison of the position ofthese stars in the fundamental HR diagram with evolutionary tracks. Thecomparison shows an overall agreement with the Y=0.30 and Z=0.02 trackscomputed with OPAL opacities and moderate amount of overshooting fromthe convective core. In addition, we present evidence that systematicerrors of the masses read off the evolutionary tracks are below 10%.Consequently, the surface gravities obtained from these "evolutionary"masses and the empirical radii are very nearly model-independent.Spectrographic and photometric observations of these stars can thereforebe used for verifying model atmospheres and calibrating photometric logg indices. Hipparcos: The StarsNot Available Radial velocities of HIPPARCOS southern B8-F2 type starsRadial velocities have been determined for a sample of B8-F2 type starsobserved by the Hipparcos satellite. Observations were obtained withinthe framework of an ESO key-program. Radial velocities have beenmeasured using a cross-correlation method, the templates being a grid ofsynthetic spectra. The obtained precision depends on effectivetemperature and projected rotational velocity of the star as well as ona possible asymmetry of the correlation peak generally due to secondarycomponents. New spectroscopic binaries have been detected from theseasymmetries and the variability of the measured radial velocity.Simulations of binary and triple systems have been performed. Forbinaries our results have been compared with Hipparcos binary data.Adding the variable radial velocities, the minimum binary fraction hasbeen found 60% for physical systems. Radial velocities have beendetermined for 581 B8-F2 stars, 159 being new. Taking into accountpublished radial velocities, 39% south A-type stars with V magnitudelower than 7.5 have a radial velocity. Based on observations obtained atthe European Southern Observatory (ESO, La Silla, Chile) and on datafrom the ESA Hipparcos astrometry satellite.}\fnmsep \thanks{Tables 7, 8and 9 are only available in electronic form at the CDS via anonymous ftpto cdsarc.u-strasbg.fr (130.79.128.5) or viahttp://cdsweb.u-strasbg.fr/Abstract.html Towards a fundamental calibration of stellar parameters of A, F, G, K dwarfs and giantsI report on the implementation of the empirical surface brightnesstechnique using the near-infrared Johnson broadband { (V-K)} colour assuitable sampling observable aimed at providing accurate effectivetemperatures of 537 dwarfs and giants of A-F-G-K spectral-type selectedfor a flux calibration of the Infrared Space Observatory (ISO). Thesurface brightness-colour correlation is carefully calibrated using aset of high-precision angular diameters measured by moderninterferometry techniques. The stellar sizes predicted by thiscorrelation are then combined with the bolometric flux measurementsavailable for a subset of 327 ISO standard stars in order to determineone-dimensional { (T, V-K)} temperature scales of dwarfs and giants. Theresulting very tight relationships show an intrinsic scatter induced byobservational photometry and bolometric flux measurements well below thetarget accuracy of +/- 1 % required for temperature determinations ofthe ISO standards. Major improvements related to the actual directcalibration are the high-precision broadband { K} magnitudes obtainedfor this purpose and the use of Hipparcos parallaxes for dereddeningphotometric data. The temperature scale of F-G-K dwarfs shows thesmallest random errors closely consistent with those affecting theobservational photometry alone, indicating a negligible contributionfrom the component due to the bolometric flux measurements despite thewide range in metallicity for these stars. A more detailed analysisusing a subset of selected dwarfs with large metallicity gradientsstrongly supports the actual bolometric fluxes as being practicallyunaffected by the metallicity of field stars, in contrast with recentresults claiming somewhat significant effects. The temperature scale ofF-G-K giants is affected by random errors much larger than those ofdwarfs, indicating that most of the relevant component of the scattercomes from the bolometric flux measurements. Since the giants have smallmetallicities, only gravity effects become likely responsible for theincreased level of scatter. The empirical stellar temperatures withsmall model-dependent corrections are compared with the semiempiricaldata by the Infrared Flux Method (IRFM) using the large sample of 327comparison stars. One major achievement is that all empirical andsemiempirical temperature estimates of F-G-K giants and dwarfs are foundto be closely consistent between each other to within +/- 1 %. However,there is also evidence for somewhat significant differential effects.These include an average systematic shift of (2.33 +/- 0.13) % affectingthe A-type stars, the semiempirical estimates being too low by thisamount, and an additional component of scatter as significant as +/- 1 %affecting all the comparison stars. The systematic effect confirms theresults from other investigations and indicates that previousdiscrepancies in applying the IRFM to A-type stars are not yet removedby using new LTE line-blanketed model atmospheres along with the updatedabsolute flux calibration, whereas the additional random component isfound to disappear in a broadband version of the IRFM using an infraredreference flux derived from wide rather than narrow band photometricdata. Table 1 and 2 are only available in the electronic form of thispaper
Submit a new article

• - No Links Found -


text:
# Weird circular orbit problem

## Recommended Posts

Posted (edited)

I am having a strange circular orbit problem. I set up the mass of the Sun, plus Mercury's initial orbit position and velocity:

I use these parameters to calculate Mercury's path through space, via Euler integration:

The problem is, if I set Mercury's initial velocity to be sqrt(G*sun_mass/distance), then there is still some eccentricity -- the distance and velocity vector length aren't constant, like you'd expect for a perfectly circular orbit. And the discrepancy is not small, the orbit velocity length varies by 100s of metres per second, so it's not a precision issue. Anyone have any idea why my code produces unwanted results? Thanks for your time and attention.

Edited by cowcow

##### Share on other sites

How did you derive sqrt(G*sun_mass/distance)? (I assume "sum_mass" is a typo.)

##### Share on other sites

Yes. it was a typo.

I got the formula from many sites, including this one: http://orbitsimulator.com/formulas/vcirc.html

Trying the factor of 0.5, I get a very eccentric orbit. :(

##### Share on other sites

I finally found my old code for RK2 and RK4 -- it works way better with RK4 as the integrator.

##### Share on other sites

You can with a very small time step, to see if the orbit is much more circular in that case.

Ideally you would use a symplectic integrator so your planets don't gain or lose energy.

##### Share on other sites
Posted (edited)

Can you please provide some code for a symplectic integrator? I need the position vector length and velocity vector length to be constant over time, and RK4 seems to do the trick for the most part, well, much more than Euler integration does anyway. Not sure how much better a symplectic integrator could be.

Edited by cowcow

##### Share on other sites

Here's some code that uses a 4-th degree symplectic integrator:

#include <iostream>
#include <cmath>

struct Vector3 {
double x, y, z;
};

Vector3 operator+(Vector3 const &v1, Vector3 const &v2) {
return Vector3{v1.x + v2.x, v1.y + v2.y, v1.z + v2.z};
}

Vector3 &operator+=(Vector3 &v1, Vector3 const &v2) {
v1.x += v2.x;
v1.y += v2.y;
v1.z += v2.z;

return v1;
}

Vector3 operator-(Vector3 const &v1, Vector3 const &v2) {
return Vector3{v1.x - v2.x, v1.y - v2.y, v1.z - v2.z};
}

Vector3 operator*(double scalar, Vector3 const &v) {
return Vector3{scalar * v.x, scalar * v.y, scalar * v.z};
}

Vector3 operator*(Vector3 const &v, double scalar) {
return scalar * v;
}

double length(Vector3 const &v) {
return std::sqrt(v.x * v.x + v.y * v.y + v.z * v.z);
}

std::ostream &operator<<(std::ostream &os, Vector3 const &v) {
return os << '(' << v.x << ',' << v.y << ',' << v.z << ')';
}

// Taken from Wikipedia's example of a 4th-order symplectic integrator
void SI_order4(Vector3 &x, Vector3 &v, Vector3 (*Acceleration)(Vector3 const &), double delta_t) {
double const cr2 = std::pow(2.0, 1.0/3.0);
double const c[4] = {
1.0/(2.0*(2.0-cr2)),
(1.0-cr2)/(2.0*(2.0-cr2)),
(1.0-cr2)/(2.0*(2.0-cr2)),
1.0/(2.0*(2.0-cr2))
};
double const d[4] = {
1.0/(2.0-cr2),
-cr2/(2.0-cr2),
1.0/(2.0-cr2),
0.0
};

for (int s = 0; s < 4; ++s) {
x += c[s] * delta_t * v;
v += d[s] * delta_t * Acceleration(x);
}
}

double const gravitational_constant = 1.0;
double const sun_mass = 1.0;
Vector3 const mercury_initial_position{0.0, 1.0, 0.0};
Vector3 const mercury_initial_velocity{1.0, 0.0, 0.0};
double const delta_t = 0.02;

Vector3 gravitational_acceleration(Vector3 const &x) {
return - gravitational_constant * sun_mass / std::pow(length(x), 3) * x;
}

int main() {
Vector3 x = mercury_initial_position;
Vector3 v = mercury_initial_velocity;

for (int i = 0; i < 158; ++i) {
std::cout << "x=" << x << " v=" << v << " (distance=" << length(x) << ", speed=" << length(v) << ")\n";
SI_order4(x, v, gravitational_acceleration, delta_t);
}

}

Enjoy!

##### Share on other sites

Holy cow. I'll implement that in my code sometime soon. Thank you so very much for the nice C++ code!

##### Share on other sites

For some reason I can now log in to my old account. So long cowcow.

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account

• 17
• 15
• 10
• 10
• 12


text:
### F MACHINE-DEPENDENT FEATURES

F.1 File Naming

F.3 File Mapping

F.5 File Locking

Although the implementations of HDS on different computer systems have been made as similar as possible, there are necessarily some differences in behaviour (especially compared to earlier VAX/VMS implementations) due to the underlying operating system. This appendix describes the behaviour for the operating systems on which HDS is currently supported.

#### F.1 File Naming

This section describes the naming rules for files when opening individual HDS container files. The rules used when searching for container files using the “wild-carding” facilities provided by HDS_WILD differ slightly (see §F.2).

File names may contain characters of either case on UNIX systems and HDS therefore does not perform any case conversion on file names. All leading and trailing white space on file names is ignored.

If a file name does not have an extension (i.e. does not have a period in the last field of its UNIX pathname), then HDS provides a default extension by appending ‘.sdf’ to the name. This occurs both when searching for existing files and when creating new ones. To make it possible to create file names without a period if required, HDS will also remove exactly one period (if present) from the end of a file name before using it.

If a file name contains any “special” characters10 and the value of the SHELL tuning parameter (§15.2) indicates that a shell is to be used for interpreting such file names, then the name will be passed to a process running the required shell for expansion before use. Thus any shell expression resulting in a valid file name may be used, such as:

$MY_DIR/datafile /reduce/data ‘cat myfilelist‘ (the precise syntax and capabilities depending on which shell is selected). The actual algorithm used for expanding file names is described in §F.2. If expansion results in more than one file name, then only the first one is used. There are no file version numbers on UNIX systems. If an existing file name is given as the name of a new output file, then the original file will be over-written. It is an error to specify a file which has already been opened by HDS (e.g. for input) as the name of a new output file. #### F.2 Wild-Card File Searching When searching for HDS container files using the “wild-card” facilities provided by HDS_WILD and HDS_EWILD, the following rules apply. Since traditional UNIX systems do not generally provide callable pattern-matching facilities for finding files, nor do they support the concept of default file type extensions, HDS implements these by passing wild-card file names to a shell process and expanding them using the following algorithm: (1) The string supplied (which may also be a list of files or file specifications separated by white space) is first expanded with the shell’s file name expansion facility turned off. This performs operations such as environment variable substitution and execution of embedded shell commands, but leaves pattern-matching characters in place. (2) The resulting string is then scanned as a list of file specifications separated by white space. (3) If any element of this list does not contain a file type extension, as indicated by the absence of a period in the final field (fields being separated by slash characters ‘/’), then an extension of ‘.sdf’ is appended to it. If an element initially ends in a period, then this is removed and no extension is added. This stage performs file type defaulting on all elements of the list consistent with the rules applied to individual file names (§F.1). (4) The resulting list of file specifications is then expanded with the shell’s file name expansion facility turned on, resulting in the final list of files. HDS will further filter the list of files found to exclude any which appear not to exist, cannot be accessed, or are not valid HDS container files. #### F.3 File Mapping The sun4_Solaris and alpha_OSF1 implementations of HDS currently provide a choice between the use of file mapping to perform I/O operations on primitive objects and the use of direct read/write operations. This is selectable via the ‘MAP’ tuning parameter (see §15.2). The default is to use file mapping on both systems. Only read/write operations will be supported on other systems, regardless of the setting of the ‘MAP’ tuning parameter. #### F.4 Scratch Files The environment variable HDS_SCRATCH is used on UNIX systems to define the directory in which HDS will create scratch container files to hold temporary objects created with DAT_TEMP. When creating a scratch file, HDS will use the file name:$HDS_SCRATCH/$<$filename$>$

where \$HDS_SCRATCH is the translation of this environment variable. If HDS_SCRATCH is undefined, then the file name will be used alone, so that scratch files will then be created in the current directory.

#### F.5 File Locking

HDS file locking is not currently implemented on UNIX systems. This means that any number of processes may access a container file simultaneously. This should not be allowed to happen, however (apart from shared read access), because modifications to the file will not be propagated consistently between the file and the separate processes. The result will be a corrupted container file and/or hung or crashed processes.

Note that HDS supports access to container files over the Network File System (NFS), but does not provide file locking.

10That is, anything except alphanumeric characters, slash ‘/’, period ‘.’, underscore ‘_’ and minus ‘$-$’.


text:
# Talk:Piano key frequencies

## Tenor C

Keyboard instrumentalists call C3 Tenor C, not C5. We generaly use these terms: Bass C (C2), Tenor C (c3), Middle C (c4), Soprano C (c5). This is due to the range of our instrument and not based around the range of vocalists (as C5 for Tenor C would be). Most early keyboard instruments didn't extend much past C2 and C6. This can still be observed by looking at the keyboard of the modern organ. -Z. (05/15/08)

This table needs to be wikified. I'll try to get to it later. Not much time on line these days. Merry Christmas! Quinobi 13:56, 25 Dec 2004 (UTC)

• This piano is upside down. High notes are low, and low ones high. If you turn your head left so the black keys are above the note names (as is natural), the high notes are on the left, the exact opposite of a piano. --Wahoofive 17:23, 18 Mar 2005 (UTC)
• Well, if you look at how the frequencies are derived from the Twelfth root of two schema, you logically start at the 'bottom' or lowest frequency, which is A0 (or is it A1?) on a modern piano.Quinobi 09:26, 28 Apr 2005 (UTC)
• This could be solved by placing the notes to the right of the Scientific Name/Frequency. —Preceding unsigned comment added by 65.110.231.134 (talk) 23:49, 17 September 2007 (UTC)
• I don't see how that follows. The frequences are derived from A440, which is more or less in the middle. Anyway, somebody already changed it. —Wahoofive (Talk) 16:05, 28 Apr 2005 (UTC)
• Take a look below at Octaves, Notes, Frequencies, and Appearance and let us know if you think that this needs any more work. hydnjo talk 19:43, 28 Apr 2005 (UTC)

## VfD removal

Consensus was to keep, but under a new name (Piano key frequencies). There were a few votes to move, but not for that specific name: if anyone objects to that new name, feel free to bring it up here.

Here is the archived discussion: Wikipedia:Votes_for_deletion/Virtual_piano. Antandrus 21:24, 9 Apr 2005 (UTC)

• Hey, good. I Like the new name. Thanks. Quinobi 09:16, 28 Apr 2005 (UTC)

## Oops

It appears that this piano is one octave too high. Since it's not completely trivial to fix I'll do it when I have a few minutes (unless someone gets to it first). The lowest note is A0, not A1 (notice that the dashes are confusing --there is an A-1, but not on a piano) and the top note is C8. In the Yamaha system, common on MIDI synthesizers, Middle C is C3; this sometimes causes confusion. Antandrus 22:43, 25 Apr 2005 (UTC)

There isn't really a standard for octave numbering. Middle C is sometimes C3, sometimes C5, sometimes C4, depending on who is writing. Aternatively some use: CC C c c' etc... It really doesn't matter what you use as long as it's consistent and understandable. Rainwarrior 18:46, 1 April 2006 (UTC)

## Octaves, Notes, Frequencies, and Appearance

The keys now go from A0 to C8 as they should and with their proper frequencies. Also, the high notes are at the top which seems more natural, and the black notes are defined with both sharp and flat notation (#/b) so as to avoid confusion. And finally, the width has been adjusted to make the keys appear more like the aspect ratio of a keyboard. Thank you to Antandrus for all the tedious editing and to all the others who have helped along the way. I hope this article is done, but if it's not, well then feel free. hydnjo talk 19:38, 28 Apr 2005 (UTC)

• Looks good. I made a few tweaks, like adding missing slashes. I took the width parameter completely off the table; tell me if it looks significantly different (it changed the word wrapping a little). But articles on Wikipedia are never "done." —Wahoofive (talk) 20:41, 28 Apr 2005 (UTC)
Thanks again. It looks fine. I must have been editing the dual notation with the missing slashes during cocktail time.  ;-) hydnjo talk 11:51, 29 Apr 2005 (UTC)

## Reverse Frequency Formula

I didn't know where to put this but here is a formula I had just worked out to get the note index based on a frequency (or at least close to it considering rounding). It was very useful in my application to index it this way so it may be useful for others to have it clearly typed out.

• Symboliclly: 12/log2(log(F) - Log(440*2^(-49/12))) = Note Index
• Decimals: 39.863137*(log(F) - 1.41424686) = Note Index
• It should be noted that both should be put on the page, since decimal points are important and the more accurate the better —Preceding unsigned comment added by Bamaboy1217 (talkcontribs) 21:26, 7 August 2009 (UTC)

## Article Title

The article is not at all about Piano keys. It should be titled “Frequencies in the Diatonic Equal-tempered Scale” or something like that.   — Chris Capoccia TC 13:29, 27 July 2006 (UTC) (Changed Diatonic to Equal-tempered. Rainwarrior is right about the name of the scale   — Chris Capoccia TC 19:32, 27 July 2006 (UTC))

In what way is it not about piano keys? The primary datum in each row is the piano key, followed by the note name and frequency. Very useful, I found this article when I googled 'piano frequencies' and I found what I was looking for here. HighInBC 14:06, 27 July 2006 (UTC)

Because all kinds of instruments make these tones, not just pianos. Pianos were not even the first instrument to make these tones. These tones make up the Diatonic scale Equal-tempered scale, and are not restricted to any one instrument.   — Chris Capoccia TC 15:23, 27 July 2006 (UTC) (Changed Diatonic to Equal-tempered. Rainwarrior is right about the name of the scale   — Chris Capoccia TC 19:32, 27 July 2006 (UTC))

I did not know that, I thought pianos used a subtle variation to that scale. HighInBC 15:58, 27 July 2006 (UTC)

"Diatonic" would be the wrong name for this. The diatonic scale has 7 notes to the octave, not 12, and no fixed tuning (there are many ways to make a diatonic scale). This is twelve tone equal temperament. - Rainwarrior 18:10, 27 July 2006 (UTC)

The "scientific" or "just" scale uses evenly spaced notes (frequency ratio of the twelfth root of two), but the standard musical scale is slightly different.

Not sure how relevent this is to the tipic at hand. HighInBC 16:00, 27 July 2006 (UTC)

We certainly shouldn't have the word "just" there. It's already got a very distinct meaning in tuning theory that is not that. (See just intonation). - Rainwarrior 18:10, 27 July 2006 (UTC)
Equal tempered chromatic scale frequencies? I can think of titles that are more precise, but they tend to be much longer. Ideas? Antandrus (talk) 16:19, 27 July 2006 (UTC)
This set of frequencies seems much more applicable to a synthesizer controlled by a piano sized keyboard. Someone pointed out above that a piano is slightly different than equal temperament, which it is (see Piano acoustics or Piano tuning). Basically the only thing truly "piano" about this is the 88 keys. In fact, didn't this page used to be called "Virtual piano"? "Frequencies of equal temperament" might be a better title. - 18:05, 27 July 2006 (UTC)

I probably never would have found this article if it was called "Frequencies of equal temperament". I was looking for the frequencies of piano keys, and that is what I found when I got here. I think the name apt as it is. HighInBC 19:04, 27 July 2006 (UTC)

MIT calls their list Frequencies for equal-tempered scale.   — Chris Capoccia TC 19:32, 27 July 2006 (UTC)

As that list has more notes on it than a piano has keys, perhaps it is an apt name for their list. Ours has only frequencies for piano keys, thus the name seems proper as is. HighInBC 18:34, 19 September 2006 (UTC)

## octave numbers, middle C and A440

On listening to the OGG file of 440Hz (double checked on a software signal generator), i noticed that that note is actually an A 2 octaves higher than the open A string of the guitar, (which everyone says is supposed to be A440 / A4, but perhaps they set it by the strings's 4th harmonic).

As far as i can tell from listening, the open A string on the guitar (which must be A2=110Hz if its 2 octaves below A4=440Hz) is the A BELOW the piano's middle C (as i don't have a piano, my measure of middle C is C4 from the http://en.wikipedia.org/wiki/Image:Pitch_notation.png image played on guitar), making middle C = 130.8Hz = C3.

Something doesn't add up here. Can someone please explain this?--KX36 15:43, 25 March 2007 (UTC)

The guitar's A string is notated as the A below middle C, and the guitar is a transposing instrument playing an octave lower than written. So the open string A is actually 110Hz. Read the guitar article for further information. —Wahoofive (talk) 16:38, 25 March 2007 (UTC)

A 440 is the A above middle C. —Preceding unsigned comment added by Zbryanpianist (talkcontribs) 20:05, 15 May 2008 (UTC)

I've long had issues trying to cross between various instruments in terms of pitch (especially with the octave transposition on guitars and bases), so I took the liberty to add equivalent open strings of guitars and string quartet instruments. 75.68.171.194 (talk) 01:49, 1 August 2009 (UTC)

## Helmholtz pitch names

Hi,

I've been bold and inserted the note names using the Helmholtz pitch notation for those who don't use the Scientific A0-C8 notation. If I have caused any errors, feel free to correct, or post on my talk page. I've also converted the unicode flats/sharps into {{music}} so they display in IE.

MDCollins (talk) 16:09, 6 August 2007 (UTC)

## Other instruments

Several other instruments have been added. Perhaps we should consider renaming the article into "Instrument Frequencies". −Woodstone (talk) 12:11, 1 August 2009 (UTC)

## Frequency Equation

Hello, I derived the equation ${\displaystyle f(n)=440\times 2^{\frac {n-49}{12}}\,}$ just fine, but I was wondering if it could be rewritten to look a little easier (and less arbitrary) if the constant out front is not 440, but instead ${\displaystyle {\frac {440}{\sqrt[{12}]{2^{49}}}}\approx {\frac {27.5}{\sqrt[{12}]{2^{1}}}}\approx 25.95654}$ where 27.5 is the first note on the piano. Not vitally important, but the equation is a bit simpler, though less memorable and less precise? Or just as ${\displaystyle f(n)=27.5\times 2^{\frac {n-1}{12}}\,}$ which is neither messy nor forgettable. —Preceding unsigned comment added by Andye (talkcontribs) 22:02, 13 May 2011 (UTC)

The equation is more complicated than it needs to be:

${\displaystyle f(n)=440\times 2^{\frac {n-49}{12}}\,}$

The expression in the power can be broken down, resulting in

${\displaystyle f(n)=25.9565436\times 1.0594631^{n}}$

or maybe a modestly less accurate

${\displaystyle f(n)=25.956\times 1.0595^{n}}$

It's less button-pushing (for manual calculations) and fewer math operations (for computational efficiency).

The accuracy of the last one:

${\displaystyle f(4)=32.707\approx 32.70}$ (0.02% error)

${\displaystyle f(88)=4199.\approx 4186}$ (0.31% error)

2602:306:CED0:6D20:1D56:84B9:7741:2E69 (talk) 02:44, 31 July 2012 (UTC)

The formula shows clearly how it is conceived: a 12-tone equal tuning with note 49 defined as 440 Hz. Why ruin a perfectly good formula by introducing arbitrary rounding? It is also easily modifiable, in case one would like to play for example an A 435 tuning, or if one would prefer to assign A440 to note 69, as in MIDI. −Woodstone (talk) 06:34, 31 July 2012 (UTC)
Yes, the formula is not just there for plugging into a calculator or spreadsheet; it shows the mathematical basis for the series of frequencies. As Woodstone said, it allows for adjustment of parameters such as reference frequency and distance of the reference note from the bottom of the series. __ Just plain Bill (talk) 14:38, 31 July 2012 (UTC)

## Extensions?

It would make sense to also include the notes from C0 to G0, as well as D8 to F8, as these notes appear on some pianos (although the standard range is undoubtedly still A0 to C8). Double sharp (talk) 08:02, 31 January 2014 (UTC)


text:
# FX Spot Delta market standard calculation (Trader View)

I am just writing my thesis about FX instrument and hedging and one question popped up which I can't solve. Maybe it is silly but cant find anything about it how the delta of a fx spot is defined and I want to hedge it with an option in USD Deltas. The delta of an option is easy just the first derivative of the Garman-Kohlhagen option pricing formula.

I have a GBP/USD FX-SPot trade with T+2 settlement period and the deal is made today on the 8/13/2019. The spot date would be 8/15/2019 (physical exchange). I have the folling parameters:

$$\Delta_{USD_{T+2}} \approx Notional_{GBP} * pips$$

The question is how can I discount the delta to be the value of today.

How would I now discount the delta to today in terms of T+2 to T?

I would use the instantaneous fx spot rate: $$FX_{instantaneous_{GBP/USD}} = FX_{Spot}-(ON+TN)$$ but how can I use it in the approximation above?

If I would look into a USD/CHF FX-Spot trade the delta would look like:

$$\Delta_{USD_{T}} \approx Notional_{USD} * pips = \Delta_{CHF}/FX_{instantaneous_{USD/CHF}}$$

So my two questions:

1. How can I discount the USD $$\Delta$$ for GBP/USD FX-Spot?
2. Does the approximation makes sense for USD/CHF?

If not what approach should I use?

• I think you may be overcomplicating things. The Garman Kohlagen delta is with respect to Spot, and the delta of Spot with respect to Spot is just one. Aug 16 '19 at 17:36
• Also, "hedging" spot with options doesn't make sense.
– will
Aug 16 '19 at 18:08
• @AlexC, Not in the tardes view. Because 1 is not the proper delta. Here the pips ar eimportant or the curves. Aug 17 '19 at 7:28
• @will: Why? If I have FX-Spot expiring in two days on a physical delivery of an FX-Spot I should hedge it an Option right? Aug 17 '19 at 9:31

This will be too late for your thesis but you mix up a few concepts. If it does not help you anymore, it may help others.

Spot does not have delta (well it is delta one, as delta is defined as the change in value due to change in spot - hence, logically spot delta is 1, as you ask for change in spot for change in spot).

FX options are actually quoted in delta. Uwe Wystup and Dimitri Reswich explains this nicely. Many currencies switch from ATMS to AMTF after 1 year.

In terms of computing ATMD, ATMF, and ATMS; I simply refer to the aforementioned paper. Table 2 shows Spot vs forward delta.

What you refer to is the distinction between time to delivery vs time to expiry (I suppose). The later is usually from pricing date (when the structure is entered) to expiry (when spot fixing is observed). The former refers to the difference between delivery and premium date (what you say is T+2) but that is not generally applicable (there are T+1 currencies, deferred premia etc.).

Ignoring all this, Spot delta is really just forward delta, $$N(d1)$$, discounted $$exp^{-ccy2*\tau}*FwdDelta$$. This discount factor is using time to delivery (premium date to delivery date). Usually, premium date is spot date (which is in turn T+2 for many currencies).

Now that concludes the logical argument. Spot delivery is T+2. If option delta is premium date to delivery, you have zero time difference between premium and delivery in spot. Hence, why spot is delta 1 again.

ON and TN are not even forwards but swaps. It makes no sense to use these to (delta) hedge spot. You enter spot today, for delivery in T+2(in many cases).

Last but not least, delta hedging involves buying spot. If you would have to delta hedge spot again, it would defeat the purpose of hedging with spot in the first place.


text:
# Hanging chain problem

Hanging chain problem
State dimension: 1
Differential states: 3
Continuous control functions: 1
Path constraints: 4
Interior point equalities: 5

The Hanging chain problem is concerned with finding a chain (of uniform density) of length $L$ suspendend between two points $a, b$ with minimal potential energy. (Problem taken from the COPS library)

## Mathematical formulation

The problem is given by

$\begin{array}{llcl} \displaystyle \min_{x, u} & x_2(t_f) \\[1.5ex] \mbox{s.t.} & \dot{x}_1 & = & u, \\ & \dot{x}_2 & = & x_1 (1+u^2)^{1/2}, \\ & \dot{x}_3 & = & (1+u^2)^{1/2}, \\ & x(t_0) &=& (a,0,0)^T, \\ & x_1(t_f) &=& b, \\ & x_3(t_f) &=& Lp, \\ & x(t) &\in& [0,10], \\ & u(t) &\in& [-10,20]. \end{array}$

## Parameters

In this model the parameters used are

$\begin{array}{rcl} [t_0, t_f] &=& [0, 1],\\ (a,b) &=& (1,3),\\ Lp &=& 4. \end{array}$

## Source Code

Model descriptions are available in


text:
# Tag Info

## Hot answers tagged symbolic

6

Everything you want in the question can be done by defining the derivative of the Norm: Derivative[1][Norm][z_] := z/Norm[z] D[Norm[x - y], {x}] (* ==> (x - y)/Norm[x - y] *) Simplify[D[Norm[x - y], {y}]] (* ==> (-x + y)/Norm[x - y] *) Here, the syntax I used for the derivatives is such that it would remain valid if x or y were replaced by vectors ...

5

You can do something like this: Simplify[Sqrt[x^2]] (* Sqrt[x^2] *) $Assumptions = _ ∈ Reals (* _ ∈ Reals *) Simplify[Sqrt[x^2]] (* Abs[x] *) This tells those functions that have an Assumptions option that any expression is considered real. Caveat: This refers to any expression, not just any variable! So you get this now: Simplify[Sqrt[x] ∈ Reals] (* ... 2 To some extent (and with some care) this can be done with FeynCalc. At least I used it several times when I needed to compute gradients and divergences of Cartesian vectors. The trick is to work with D-dimensional 4-vectors and take the limit$D \to 3\$ at the end. Since FeynCalc doesn't distinguish between upper and lower indices, the results are the same as ...

Only top voted, non community-wiki answers of a minimum length are eligible


text:
# How to calculate $\frac{1}{p - 1} \mod p$?

I'm trying to use Wilson's theorem to simplify $(p - 2)! \mod p$, for a prime $p$. From the theorem it follows that it is equivalent to $\frac{1}{p - 1} \mod p$, but this isn't an integer so I'm not too sure what to do with it.

Is my deduction incorrect? Or am I just missing how to calculate the modulos of a fraction?

• $p-1\equiv -1\pmod p$ so...
– lulu
Oct 20 '16 at 15:30

## 4 Answers

By definition, $1/b\pmod{p}$ means the multiplicative inverse of $b$ in $\Bbb Z/(p)$. That is, $1/b$ is the element $u$ of $\Bbb Z/(p)$ such that $bu\equiv 1\pmod{p}$. In your case, you need to find an element $u$ such that $u(p-1)\equiv 1\pmod{p}$. But $p-1\equiv -1\pmod{p}$, so $u$ must be...

The value $\frac{1}{p-1}$ is probably more intuitive when written as $(p-1)^{-1}$, i.e. the number with which $p-1$ must be multiplied to obtain $1 \mod p$.

To simplify even further, note that $p-1 \equiv -1 \mod p$. What does this imply about the inverse of $p-1$?

I think you're overcomplicating things: $(p-1)!\equiv -1$ (mod $p$) by Wilson's theorem, and $p-1\equiv -1$ (mod $p$), so multiplying both sides by $-1$ we get $(p-2)!\equiv 1$ (mod $p$).

$\frac{1}{p-1}\equiv x\pmod p$ so $x(p-1)\equiv 1 \pmod p$ so
$-x\equiv 1\pmod p$ so $x\equiv -1\pmod p$


text:
# OpenGraph DrawingFramework

v. 2022.02 (Dogwood)

ogdf::NonPlanarCore< TCost > Class Template Reference

Non-planar core reduction. More...

#include <ogdf/planarity/NonPlanarCore.h>

## Classes

struct  CutEdge
Struct to represent an edge that needs to be crossed in order to cross an st-component. More...

## Public Member Functions

NonPlanarCore (const Graph &G, bool nonPlanarityGuaranteed=false)
The unweighted version of the Algorithm call and constructor. More...

NonPlanarCore (const Graph &G, const EdgeArray< TCost > &weight, bool nonPlanarityGuaranteed=false)
An slimmed version of the Algorithm call and constructor. More...

NonPlanarCore (const Graph &G, const EdgeArray< TCost > &weight, MinSTCutModule< TCost > *minSTCutModule, bool nonPlanarityGuaranteed=false)
Algorithm call and constructor. More...

virtual ~NonPlanarCore ()

const Graphcore () const
Returns the non-planar core. More...

const EdgeArray< TCost > & cost () const
Returns the costs of the edges in the core, which is the number of original edges crossed, if e is crossed, i.e. More...

TCost cost (edge e) const
Returns the cost of e, which is the number of original edges crossed, if e is crossed, i.e. More...

bool isVirtual (edge e) const
True iff the edge e in the core represents more than one orginal edge and therefore is virtual. More...

EdgeArray< edge > * mapE (edge e) const
Returns a map from the edges of the st-component represented by the core edge e to the original graph. More...

const List< CutEdge > & mincut (edge e) const
Returns the mincut of the st-component represented by e. More...

List< edgeoriginal (edge e) const
Returns the edges of the original graph, which are represented by e in the core. More...

node original (node v) const
Returns the node of the original graph, which is represented by v in the core. More...

const GraphoriginalGraph () const
Returns the original graph. More...

edge realEdge (edge e) const
Returns the edge of the orginal graph, which is represented by e or nullptr iff e is virtual. More...

void retransform (const GraphCopy &planarCore, GraphCopy &planarGraph, bool pCisPlanar=true)
Inserts the crossings from a copy of the core into a copy of the original graph. More...

node sNode (edge e) const
Returns the s node of the skeleton of the st-component represented by the core edge e = (s,t) Note that this node is not contained in the input graph, but an internal auxiliary graph. More...

node tNode (edge e) const
Returns the t node of the skeleton of the st-component represented by the core edge e = (s,t) Note that this node is not contained in the input graph, but an internal auxiliary graph. More...

## Protected Member Functions

void call (const Graph &G, const EdgeArray< TCost > *weight, MinSTCutModule< TCost > *minSTCutModule, bool nonPlanarityGuaranteed)
The private method behind the constructors. More...

void getAllMultiedges (List< edge > &winningEdges, List< edge > &losingEdges)
Checks for multiedges in the core. More...

void getMincut (edge e, List< edge > &cut)
Get the mincut of e with respect to its position in the chain of its original edge. More...

void glue (edge eWinner, edge eLoser)
Glues together the skeletons of eWinner and eLoser for pruned P- and S-nodes. More...

void glueMincuts (edge eWinner, edge eLoser)
Glues together the mincuts of the winner and the loser edge. More...

void importEmbedding (edge e)
This method asserts that all parts of the end graph that are represented by edge e internally have the same embedding every time retransform is called, regardless of which planarization of the core is given. More...

void inflateCrossing (node v)
The crossing denoted by dummy node v from the planarized copy of the core get inserted into the end graph. More...

void markCore (NodeArray< bool > &mark)
Marks all nodes of the underlying SPQRTree and prunes planar leaves until the marked nodes span a tree, which has only non-planar leaves, i.e. More...

void normalizeCutEdgeDirection (edge coreEdge)
Every edge of coreEdge's cut that doesn't go the same direction as coreEdge gets reversed. More...

void removeSplitdummies (List< node > &splitdummies)
After inserting the crossings, the end graph edges don't need to be partitioned anymore so the splitdummies get removed. More...

void splitEdgeIntoSections (edge e, List< node > &splitdummies)
To be able to insert crossings correctly, an end graph edge ought to be split into n-1 sections if n is the number of crossings on the edge. More...

void traversingPath (const Skeleton &Sv, edge eS, List< CutEdge > &path, NodeArray< node > &mapV, edge coreEdge, const EdgeArray< TCost > *weight_src, MinSTCutModule< TCost > *minSTCutModule)
Computes the traversing path for a given edge and the unmarked tree rooted in the node of eS and saves the combinatorial embedding of the st-component which eS represents, i.e. More...

## Protected Attributes

EdgeArray< TCost > m_cost
Costs to cross each edge of the core. More...

GraphCopym_endGraph
A pointer to a copy of the original graph, in which crossings are replaced by dummy nodes. More...

Graph m_graph
The core. More...

EdgeArray< EdgeArray< edge > * > m_mapE
The mapping between the edges of each embedding and their original. More...

EdgeArray< NodeArray< node > * > m_mapV
The mapping between the nodes of each embedding and their original. More...

EdgeArray< List< CutEdge > > m_mincut
Traversing path for an edge in the core. More...

NodeArray< nodem_orig
Corresp. original node. More...

const GraphCopym_planarCore
A pointer to a copy of the core, in which crossings are replaced by dummy nodes. More...

const Graphm_pOriginal
The original graph. More...

EdgeArray< edgem_real
Corresp. original edge (0 if virtual) More...

EdgeArray< nodem_sNode
The s node of the st-component of a core edge. More...

StaticSPQRTree m_T
The SPQRTree that represents the original graph. More...

EdgeArray< nodem_tNode
The t node of the st-component of a core edge. More...

EdgeArray< Graph * > m_underlyingGraphs
The graph for the underlying skeleton of a virtual edge in the core. More...

## Friends

template<typename T >
class GlueMap

## Detailed Description

### template<typename TCost = int> class ogdf::NonPlanarCore< TCost >

Non-planar core reduction.

The class ogdf::NonPlanarCore implements a reduction method that reduces a graph to a smaller core graph which behaves invariant with respect to non-planarity measures like crossing number, skewness, coarseness, and thickness. The core reduction is based on the decomposition of a graph into its triconnected components and can be computed in linear time.

The implementation is based on the following publication:

Markus Chimani, Carsten Gutwenger: Non-planar core reduction of graphs. Discrete Mathematics 309(7) (2009) 1838-1855

If the core reduction is done for a weighted graph, the running time is no longer linear, because the mincut of st-components can't be calculated via BFS anymore, but either via Dijkstra (default) on the dual graph (O(n log n)) or via any other minSTCut routine. In tests we found out that Dijkstra outperforms all other minSTCut routines for all instances.

Definition at line 66 of file NonPlanarCore.h.

## ◆ NonPlanarCore() [1/3]

template<typename Cost >
 ogdf::NonPlanarCore< Cost >::NonPlanarCore ( const Graph & G, bool nonPlanarityGuaranteed = false )
explicit

The unweighted version of the Algorithm call and constructor.

This constructor computes the non-planar core of the graph G.

Precondition
G has to be biconnected.
Parameters
 G the graph of which the NPC is to be made nonPlanarityGuaranteed iff set to true the algorithm runs a bit faster for nonplanar graphs

Definition at line 454 of file NonPlanarCore.h.

## ◆ NonPlanarCore() [2/3]

template<typename TCost = int>
 ogdf::NonPlanarCore< TCost >::NonPlanarCore ( const Graph & G, const EdgeArray< TCost > & weight, bool nonPlanarityGuaranteed = false )

An slimmed version of the Algorithm call and constructor.

This constructor computes the non-planar core of the graph G.

Precondition
G has to be biconnected.
Parameters
 G the graph of which the NPC is to be made nonPlanarityGuaranteed iff set to true the algorithm runs a bit faster for nonplanar graphs weight if the graph is weighted, the weights otherwise a nullptr

## ◆ NonPlanarCore() [3/3]

template<typename TCost = int>
 ogdf::NonPlanarCore< TCost >::NonPlanarCore ( const Graph & G, const EdgeArray< TCost > & weight, MinSTCutModule< TCost > * minSTCutModule, bool nonPlanarityGuaranteed = false )

Algorithm call and constructor.

This constructor computes the non-planar core of the graph G.

Precondition
G has to be biconnected.
Parameters
 G the graph of which the NPC is to be made nonPlanarityGuaranteed iff set to true the algorithm runs a bit faster for nonplanar graphs weight if the graph is weighted, the weights otherwise a nullptr minSTCutModule the MaxFlowModule that should be used for calculating the traversing path for weighted graphs.

## ◆ ~NonPlanarCore()

template<typename Cost >
 ogdf::NonPlanarCore< Cost >::~NonPlanarCore
virtual

Definition at line 482 of file NonPlanarCore.h.

## ◆ call()

template<typename TCost = int>
 void ogdf::NonPlanarCore< Cost >::call ( const Graph & G, const EdgeArray< TCost > * weight, MinSTCutModule< TCost > * minSTCutModule, bool nonPlanarityGuaranteed )
protected

The private method behind the constructors.

Definition at line 495 of file NonPlanarCore.h.

## ◆ core()

template<typename TCost = int>
 const Graph& ogdf::NonPlanarCore< TCost >::core ( ) const
inline

Returns the non-planar core.

Definition at line 113 of file NonPlanarCore.h.

## ◆ cost() [1/2]

template<typename TCost = int>
 const EdgeArray& ogdf::NonPlanarCore< TCost >::cost ( ) const
inline

Returns the costs of the edges in the core, which is the number of original edges crossed, if e is crossed, i.e.

one if an edge is real and |mincut(edge)| if an edge is virtual

Definition at line 157 of file NonPlanarCore.h.

## ◆ cost() [2/2]

template<typename TCost = int>
 TCost ogdf::NonPlanarCore< TCost >::cost ( edge e ) const
inline

Returns the cost of e, which is the number of original edges crossed, if e is crossed, i.e.

1 if e is real and |mincut(e)| if e is virtual

Definition at line 188 of file NonPlanarCore.h.

## ◆ getAllMultiedges()

template<typename Cost >
 void ogdf::NonPlanarCore< Cost >::getAllMultiedges ( List< edge > & winningEdges, List< edge > & losingEdges )
protected

Checks for multiedges in the core.

This method is a slightly modified version of ogdf::IsParallelFreeUndirected(), that adds the functionality that the found multiedges are stored in lists.

Parameters
 winningEdges The list of edges that will survive the glue. losingEdges The list of edges that won't survive the glue.

Definition at line 825 of file NonPlanarCore.h.

## ◆ getMincut()

template<typename Cost >
 void ogdf::NonPlanarCore< Cost >::getMincut ( edge e, List< edge > & cut )
protected

Get the mincut of e with respect to its position in the chain of its original edge.

Parameters
 e The edge that we want to know the position of in the graphcopy representing the planarized version of the original graph. cut A list to write the mincut to.

Definition at line 1151 of file NonPlanarCore.h.

## ◆ glue()

template<typename Cost >
 void ogdf::NonPlanarCore< Cost >::glue ( edge eWinner, edge eLoser )
protected

Glues together the skeletons of eWinner and eLoser for pruned P- and S-nodes.

This is done, by inserting all nodes and edges of eLoser's skeleton into eWinner's skeleton, while preserving the embedding of both skeletons.

Parameters
 eWinner the core edge that will represent the newly formed skeleton/embedding eLoser the core edge that is copied from

Definition at line 844 of file NonPlanarCore.h.

## ◆ glueMincuts()

template<typename Cost >
 void ogdf::NonPlanarCore< Cost >::glueMincuts ( edge eWinner, edge eLoser )
protected

Glues together the mincuts of the winner and the loser edge.

Parameters
 eWinner the edge whose mincut gets augmented eLoser the edge whose mincut gets glued to the winner mincut

Definition at line 1179 of file NonPlanarCore.h.

## ◆ importEmbedding()

template<typename Cost >
 void ogdf::NonPlanarCore< Cost >::importEmbedding ( edge e )
protected

This method asserts that all parts of the end graph that are represented by edge e internally have the same embedding every time retransform is called, regardless of which planarization of the core is given.

Only nodes that are present in the core can have a different embedding for a different planarization of the core. They are infact reassembling the planarization of the core.

Definition at line 1067 of file NonPlanarCore.h.

## ◆ inflateCrossing()

template<typename Cost >
 void ogdf::NonPlanarCore< Cost >::inflateCrossing ( node v )
protected

The crossing denoted by dummy node v from the planarized copy of the core get inserted into the end graph.

Definition at line 1102 of file NonPlanarCore.h.

## ◆ isVirtual()

template<typename TCost = int>
 bool ogdf::NonPlanarCore< TCost >::isVirtual ( edge e ) const
inline

True iff the edge e in the core represents more than one orginal edge and therefore is virtual.

Definition at line 144 of file NonPlanarCore.h.

## ◆ mapE()

template<typename TCost = int>
 EdgeArray* ogdf::NonPlanarCore< TCost >::mapE ( edge e ) const
inline

Returns a map from the edges of the st-component represented by the core edge e to the original graph.

Definition at line 180 of file NonPlanarCore.h.

## ◆ markCore()

template<typename Cost >
 void ogdf::NonPlanarCore< Cost >::markCore ( NodeArray< bool > & mark )
protected

Marks all nodes of the underlying SPQRTree and prunes planar leaves until the marked nodes span a tree, which has only non-planar leaves, i.e.

non-planar R-nodes.

Parameters
 mark The array where the marking is done

Definition at line 633 of file NonPlanarCore.h.

## ◆ mincut()

template<typename TCost = int>
 const List& ogdf::NonPlanarCore< TCost >::mincut ( edge e ) const
inline

Returns the mincut of the st-component represented by e.

Definition at line 193 of file NonPlanarCore.h.

## ◆ normalizeCutEdgeDirection()

template<typename Cost >
 void ogdf::NonPlanarCore< Cost >::normalizeCutEdgeDirection ( edge coreEdge )
protected

Every edge of coreEdge's cut that doesn't go the same direction as coreEdge gets reversed.

This method is used to both normalize the cutedges and denormalize them after the retransformation.

Parameters
 coreEdge the core edge

Definition at line 1021 of file NonPlanarCore.h.

## ◆ original() [1/2]

template<typename TCost = int>
 List ogdf::NonPlanarCore< TCost >::original ( edge e ) const
inline

Returns the edges of the original graph, which are represented by e in the core.

Definition at line 128 of file NonPlanarCore.h.

## ◆ original() [2/2]

template<typename TCost = int>
 node ogdf::NonPlanarCore< TCost >::original ( node v ) const
inline

Returns the node of the original graph, which is represented by v in the core.

Definition at line 123 of file NonPlanarCore.h.

## ◆ originalGraph()

template<typename TCost = int>
 const Graph& ogdf::NonPlanarCore< TCost >::originalGraph ( ) const
inline

Returns the original graph.

Definition at line 118 of file NonPlanarCore.h.

## ◆ realEdge()

template<typename TCost = int>
 edge ogdf::NonPlanarCore< TCost >::realEdge ( edge e ) const
inline

Returns the edge of the orginal graph, which is represented by e or nullptr iff e is virtual.

Definition at line 149 of file NonPlanarCore.h.

## ◆ removeSplitdummies()

template<typename Cost >
 void ogdf::NonPlanarCore< Cost >::removeSplitdummies ( List< node > & splitdummies )
protected

After inserting the crossings, the end graph edges don't need to be partitioned anymore so the splitdummies get removed.

Definition at line 1032 of file NonPlanarCore.h.

## ◆ retransform()

template<typename Cost >
 void ogdf::NonPlanarCore< Cost >::retransform ( const GraphCopy & planarCore, GraphCopy & planarGraph, bool pCisPlanar = true )

Inserts the crossings from a copy of the core into a copy of the original graph.

This method expects planarCore to be planarly embedded without pseudo-crossings.

Parameters
 planarCore a GraphCopy of the core, in which dummy nodes are inserted to represent crossings planarGraph a GraphCopy which is replaced by a GraphCopy of the original graph pCisPlanar Set this to true if a non-planar embedding of planarCore is given.

Definition at line 935 of file NonPlanarCore.h.

## ◆ sNode()

template<typename TCost = int>
 node ogdf::NonPlanarCore< TCost >::sNode ( edge e ) const
inline

Returns the s node of the skeleton of the st-component represented by the core edge e = (s,t) Note that this node is not contained in the input graph, but an internal auxiliary graph.

Definition at line 173 of file NonPlanarCore.h.

## ◆ splitEdgeIntoSections()

template<typename Cost >
 void ogdf::NonPlanarCore< Cost >::splitEdgeIntoSections ( edge e, List< node > & splitdummies )
protected

To be able to insert crossings correctly, an end graph edge ought to be split into n-1 sections if n is the number of crossings on the edge.

This method does exactly that.

Parameters
 e The edge to be split splitdummies To delete the inserted dummynodes later, we store all of them in here

Definition at line 1045 of file NonPlanarCore.h.

## ◆ tNode()

template<typename TCost = int>
 node ogdf::NonPlanarCore< TCost >::tNode ( edge e ) const
inline

Returns the t node of the skeleton of the st-component represented by the core edge e = (s,t) Note that this node is not contained in the input graph, but an internal auxiliary graph.

Definition at line 165 of file NonPlanarCore.h.

## ◆ traversingPath()

template<typename TCost = int>
 void ogdf::NonPlanarCore< Cost >::traversingPath ( const Skeleton & Sv, edge eS, List< CutEdge > & path, NodeArray< node > & mapV, edge coreEdge, const EdgeArray< TCost > * weight_src, MinSTCutModule< TCost > * minSTCutModule )
protected

Computes the traversing path for a given edge and the unmarked tree rooted in the node of eS and saves the combinatorial embedding of the st-component which eS represents, i.e.

a list of edges that are to be crossed, when the given edge is crossed in the core. This list is minimal.

Parameters
 Sv the Skeleton of one of the marked nodes of m_T. eS an edge in Sv. path a container to write the traversing path to true iff the source of the edge is on the s side of the cut. mapV a NodeArray of the original graph to map original nodes to nodes created in this method. coreEdge the edge in the core that represents the st-component of which the traversing path is computed. weight_src the weight of the edges of the original graph minSTCutModule same as in the constructor

Definition at line 683 of file NonPlanarCore.h.

## ◆ GlueMap

template<typename TCost = int>
template<typename T >
 friend class GlueMap
friend

Definition at line 69 of file NonPlanarCore.h.

## ◆ m_cost

template<typename TCost = int>
 EdgeArray ogdf::NonPlanarCore< TCost >::m_cost
protected

Costs to cross each edge of the core.

Definition at line 346 of file NonPlanarCore.h.

## ◆ m_endGraph

template<typename TCost = int>
 GraphCopy* ogdf::NonPlanarCore< TCost >::m_endGraph
protected

A pointer to a copy of the original graph, in which crossings are replaced by dummy nodes.

It's a nullptr unless NonPlanarCore::retransform was called.

Definition at line 334 of file NonPlanarCore.h.

## ◆ m_graph

template<typename TCost = int>
 Graph ogdf::NonPlanarCore< TCost >::m_graph
protected

The core.

Definition at line 319 of file NonPlanarCore.h.

## ◆ m_mapE

template<typename TCost = int>
 EdgeArray *> ogdf::NonPlanarCore< TCost >::m_mapE
protected

The mapping between the edges of each embedding and their original.

Definition at line 355 of file NonPlanarCore.h.

## ◆ m_mapV

template<typename TCost = int>
 EdgeArray *> ogdf::NonPlanarCore< TCost >::m_mapV
protected

The mapping between the nodes of each embedding and their original.

Definition at line 352 of file NonPlanarCore.h.

## ◆ m_mincut

template<typename TCost = int>
 EdgeArray > ogdf::NonPlanarCore< TCost >::m_mincut
protected

Traversing path for an edge in the core.

Definition at line 343 of file NonPlanarCore.h.

## ◆ m_orig

template<typename TCost = int>
 NodeArray ogdf::NonPlanarCore< TCost >::m_orig
protected

Corresp. original node.

Definition at line 337 of file NonPlanarCore.h.

## ◆ m_planarCore

template<typename TCost = int>
 const GraphCopy* ogdf::NonPlanarCore< TCost >::m_planarCore
protected

A pointer to a copy of the core, in which crossings are replaced by dummy nodes.

It's a nullptr unless NonPlanarCore::retransform was called.

Definition at line 328 of file NonPlanarCore.h.

## ◆ m_pOriginal

template<typename TCost = int>
 const Graph* ogdf::NonPlanarCore< TCost >::m_pOriginal
protected

The original graph.

Definition at line 322 of file NonPlanarCore.h.

## ◆ m_real

template<typename TCost = int>
 EdgeArray ogdf::NonPlanarCore< TCost >::m_real
protected

Corresp. original edge (0 if virtual)

Definition at line 340 of file NonPlanarCore.h.

## ◆ m_sNode

template<typename TCost = int>
 EdgeArray ogdf::NonPlanarCore< TCost >::m_sNode
protected

The s node of the st-component of a core edge.

Definition at line 361 of file NonPlanarCore.h.

## ◆ m_T

template<typename TCost = int>
 StaticSPQRTree ogdf::NonPlanarCore< TCost >::m_T
protected

The SPQRTree that represents the original graph.

Definition at line 349 of file NonPlanarCore.h.

## ◆ m_tNode

template<typename TCost = int>
 EdgeArray ogdf::NonPlanarCore< TCost >::m_tNode
protected

The t node of the st-component of a core edge.

Definition at line 364 of file NonPlanarCore.h.

## ◆ m_underlyingGraphs

template<typename TCost = int>
 EdgeArray ogdf::NonPlanarCore< TCost >::m_underlyingGraphs
protected

The graph for the underlying skeleton of a virtual edge in the core.

Definition at line 358 of file NonPlanarCore.h.

The documentation for this class was generated from the following file: