The current release procedure for Astropy involves a combination of an
automated release script and some manual steps. Future versions will automate
more of the process, if not all.
Release Procedure
The automated portion of the Astropy release procedure uses zest.releaser
to create the tag and update the version. zest.releaser is extendable through
hook functions–Astropy already includes a couple hook functions to modify the
default behavior, but future releases may be further automated through the
implementation of additional hook functions. In order to use the hooks,
Astropy itself must be installed alongside zest.releaser. It is recommended
to create a virtualenv specifically for this purpose.
This may seem like a lot of steps, but most of them won’t be necessary to
repeat for each release. The advantage of using an automated or semi-automated
procedure is that ensures a consistent release process each time.
Ensure you have a GPG key pair available for when git needs to sign the
tag you create for the release. See Creating a GPG Signing Key and a Signed Tag for more on
this.
Update the list of contributors in the creditsandlicense.rst file. The
easiest way to check this is do:
And just add anyone from that list who isn’t already credited.
Install virtualenv if you don’t already have it. See the linked virtualenv
documentation for details. Also, make sure that you have cython
installed, as you will need it to generate the .c files needed for the
release.
Create and activate a virtualenv:
$ virtualenv --system-site-packages --distribute astropy-release
$ source astropy-release/bin/activate
Obtain a clean version of the Astropy repository. That is, one
where you don’t have any intermediate build files. Either use a fresh
git clone or do git clean -dfx.
Be sure you’re the “master” branch or, for a bug fix release, on the
appropriate bug fix branch. For example, if releasing version 0.2.2 make
sure to:
Now install Astropy into the virtualenv:
$ python setup.py install
This is necessary for two reasons. First, the entry points for the
releaser scripts need to be available, and these are in the Astropy
package. Second, the build process will generate .c files from the
Cython .pyx files, and the .c files are necessary for the source
distribution.
Install zest.releaser into the virtualenv; use --upgrade --force to
ensure that the latest version is installed in the virtualenv (if you’re
running a csh variant make sure to run rehash afterwards too):
$ pip install zest.releaser --upgrade --force
Ensure that all changes to the code have been committed, then start the
release by running:
You will be asked to enter the version to be released. Press enter to
accept the default (which will normally be correct) or enter a specific
version string. A diff will then be shown of CHANGES.rst and setup.py
showing that a release date has been added to the changelog, and that the
version has been updated in setup.py. Enter ‘Y’ when asked to commit
these changes.
You will then be shown the command that will be run to tag the release.
Enter ‘Y’ to confirm and run the command.
When asked “Check out the tag (for tweaks or pypi/distutils server
upload)” enter ‘N’: zest.releaser does not offer enough control yet over
how the register and upload are performed so we will do this manually
until the release scripts have been improved.
You will be asked to enter a new development version. Normally the next
logical version will be selected–press enter to accept the default, or
enter a specific version string. Do not add ”.dev” to the version, as
this will be appended automatically (ignore the message that says ”.dev0
will be appended”–it will actually be ”.dev” without the 0). For
example, if the just-released version was “0.1” the default next version
will be “0.2”. If we want the next version to be, say “0.1.1”, or “1.0”,
then that must be entered manually.
You will be shown a diff of CHANGES.rst showing that a new section has
been added for the new development version, and showing that the version
has been updated in setup.py. Enter ‘Y’ to commit these changes.
When asked to push the changes to a remote repository, enter ‘Y’. This
should complete the portion of the process that’s automated at this point.
Check out the tag of the released version. For example:
Create the source distribution by doing:
Copy the produced .tar.gz somewhere and verify that you can unpack it,
build it, and get all the tests to pass. It would be best to create a new
virtualenv in which to do this.
Register the release on PyPI with:
$ python setup.py register
Upload the source distribution to PyPI; this is preceded by re-running
the sdist command, which is necessary for the upload command to know
which distribution to upload:
$ python setup.py sdist upload
Update the “stable” branch to point to the new stable release For example:
$ git checkout stable
$ git reset --hard v0.1
Update Readthedocs so that it builds docs for the corresponding github tag.
Also verify that the stable Readthedocs version builds correctly for
the new version (it should trigger automatically once you’ve done the
previous step.)
If this was a major/minor release (not a bug fix release) create a bug fix
branch for this line of release. That is, if the version just released
was “v<major>.<minor>.0”, create bug fix branch with the name
“v<major>.<minor>.x”. Starting from the commit tagged as the release,
just checkout a new branch and push it to the remote server. For example,
after releasing version 0.3, do:
Then edit setup.py so that the VERSION variable is
'0.3.1.dev', and commit that change. Then, do:
$ git push upstream v0.3.x
Note
You may need to replace upstream here with astropy or
whatever remote name you use for the main astropy repository.
The purpose of this branch is for creating bug fix releases like “0.3.1”
and “0.3.2”, while allowing development of new features to continue in
the master branch. Only changesets that fix bugs without making
significant API changes should be merged to the bug fix branches.
- Create a bug fix label on GitHub; this should have the same name as the
just created bug fix branch prepended with “backport-”. For the previous
example this would be “backport-0.3.x” This label should be applied to
all issues that should be backported to the bug fix branch. Also create a
milestone for the next bug fix release if it hasn’t been made already.
- Update astropy/astropy-website
for the new version. Two files need to be updated: index.rst has two tags
near the top specifying the current release, and the docs.rst file should
be updated by putting the previous release in as an older version, and updating
the “latest developer version” link to point to the new release.
- Run the upload_script.py script in astropy-website to update the actual
web site.
Modifications for a beta/release candidate release
For major releases with a lot of changes, we sometimes do beta and/or
release candidates to have a chance to catch significant bugs before the true
release. If the release you are performing is this kind of pre-release, some
of the above steps need to be modified. The primary difference is that these
releases go on the http://testpypi.python.org server instead of the regular
PyPI. The testpypi server provides a place to test the release and host it,
but never appears anywhere on the regular server. The price is that testpypi
is not guaranteed to be up long-term, but for short-term pre-releases, this is
no problem.
The primary modifications to the release procedure are:
- When prompted for a version number (step #13), you will need to manually
enter something like “1.0b1” or “1.0rc1”. You should follow this numbering
scheme (x.yb# or x.y.zrc#), as it will ensure the release is
ordered “before” the main release by various automated tools.
- On steps #18 and #19, where you register and upload to PyPI, it is important
that you add the option -r https://testpypi.python.org/pypi. This
ensures the release information and files are sent to the test server instead
of the real PyPI server. This will probably require you to set up a
~/.pypirc file appropriate for the testpypi server. See
https://wiki.python.org/moin/TestPyPI for more on how to do this.
- Do not do step #20 or later, as those are tasks for an actual release.
Note
~/.pypirc files necessary for uploading to the testpypi server
require you to include your password to be able to manage to do
register properly. This can be insecure, because it means you have
to put your PyPI password in a plain-text file. So you’ll want to set
the ~/.pypirc file permissions to be quite restrictive, use a
temporary PyPI password just for doing releases, or some other measure
to ensure your password remains secure.
Maintaining Bug Fix Releases
Astropy releases, as recommended for most Python projects, follows a
<major>.<minor>.<micro> version scheme, where the “micro” version is also
known as a “bug fix” release. Bug fix releases should not change any user-
visible interfaces. They should only fix bugs on the previous major/minor
release and may also refactor internal APIs or include omissions from previous
releases–that is, features that were documented to exist but were accidentally
left out of the previous release. They may also include changes to docstrings
that enhance clarity but do not describe new features (e.g., more examples,
typo fixes, etc).
Bug fix releases are typically managed by maintaining one or more bug fix
branches separate from the master branch (the release procedure below discusses
creating these branches). Typically, whenever an issue is fixed on the Astropy
master branch a decision must be made whether this is a fix that should be
included in the Astropy bug fix release. Usually the answer to this question
is “yes”, though there are some issues that may not apply to the bug fix
branch. For example, it is not necessary to backport a fix to a new feature
that did not exist when the bug fix branch was first created. New features
are never merged into the bug fix branch–only bug fixes; hence the name.
In rare cases a bug fix may be made directly into the bug fix branch without
going into the master branch first. This may occur if a fix is made to a
feature that has been removed or rewritten in the development version and no
longer has the issue being fixed. However, depending on how critical the bug
is it may be worth including in a bug fix release, as some users can be slow to
upgrade to new major/micro versions due to API changes.
Issues are assigned to an Astropy release by way of the Milestone feature in
the GitHub issue tracker. At any given time there are at least two versions
under development: The next major/minor version, and the next bug fix release.
For example, at the time of writing there are two release milestones open:
v0.2.2 and v0.3.0. In this case, v0.2.2 is the next bug fix release and all
issues that should include fixes in that release should be assigned that
milestone. Any issues that implement new features would go into the v0.3.0
milestone–this is any work that goes in the master branch that should not
be backported. For a more detailed set of guidelines on using milestones, see
Using Milestones and Labels.
Backporting fixes from master
Most fixes are backported using the git cherry-pick command, which applies
the diff from a single commit like a patch. For the sake of example, say the
current bug fix branch is ‘v0.2.x’, and that a bug was fixed in master in a
commit abcd1234. In order to backport the fix, simply checkout the v0.2.x
branch (it’s also good to make sure it’s in sync with the main Astropy
repository) and cherry-pick the appropriate commit:
$ git checkout v0.2.x
$ git pull upstream v0.2.x
$ git cherry-pick abcd1234
Sometimes a cherry-pick does not apply cleanly, since the bug fix branch
represents a different line of development. This can be resolved like any
other merge conflict: Edit the conflicted files by hand, and then run
git commit and accept the default commit message. If the fix being
cherry-picked has an associated changelog entry in a separate commit make
sure to backport that as well.
What if the issue required more than one commit to fix? There are a few
possibilities for this. The easiest is if the fix came in the form of a
pull request that was merged into the master branch. Whenever GitHub merges
a pull request it generates a merge commit in the master branch. This merge
commit represents the full difference of all the commits in the pull request
combined. What this means is that it is only necessary to cherry-pick the
merge commit (this requires adding the -m 1 option to the cherry-pick
command). For example, if 5678abcd is a merge commit:
$ git checkout v0.2.x
$ git pull upstream v0.2.x
$ git cherry-pick -m 1 5678abcd
In fact, because Astropy emphasizes a pull request-based workflow, this is the
most common scenario for backporting bug fixes, and the one requiring the
least thought. However, if you’re not dealing with backporting a fix that was
not brought in as a pull request, read on.
If not cherry-picking a merge commit there are still other options for dealing
with multiple commits. The simplest, though potentially tedious, is to simply
run the cherry-pick command once for each commit in the correct order.
However, as of Git 1.7.2 it is possible to merge a range of commits like so:
$ git cherry-pick 1234abcd..56789def
This works fine so long as the commits you want to pick are actually congruous
with each other. In most cases this will be the case, though some bug fixes
will involve followup commits that need to back backported as well. Most bug
fixes will have an issues associated with it in the issue tracker, so make sure
to reference all commits related to that issue in the commit message. That way
it’s harder for commits that need to be backported from getting lost.
Making fixes directly to the bug fix branch
As mentioned earlier in this section, in some cases a fix only applies to a bug
fix release, and is not applicable in the mainline development. In this case
there are two choices:
- An Astropy developer with commit access to the main Astropy repository may
check out the bug fix branch and commit and push your fix directly.
- Preferable: You may also make a pull request through GitHub against the
bug fix branch rather than against master. Normally when making a pull
request from a branch on your fork to the main Astropy repository GitHub
compares your branch to Astropy’s master. If you look on the left-hand
side of the pull request page, under “base repo: astropy/astropy” there is
a drop-down list labeled “base branch: master”. You can click on this
drop-down and instead select the bug fix branch (“v0.2.x” for example). Then
GitHub will instead compare your fix against that branch, and merge into
that branch when the PR is accepted.
Preparing the bug fix branch for release
There are two primary steps that need to be taken before creating a bug fix
release. The rest of the procedure is the same as any other release as
described in Release Procedure (although be sure to provide the
right version number).
- Any existing fixes to the issues assigned to the current bug fix release
milestone, or labeled with the relevant “backport-x.y.z” label must be
merged into the bug fix branch.
- The Astropy changelog must be updated to list all issues–especially
user-visible issues–fixed for the current release. The changelog should
be updated in the master branch, and then merged into the bug fix branch.
Most issues should already have changelog entries for them. But it’s
typical to forget this, so if doesn’t exist yet please add one in
the process of backporting. See Updating and Maintaining the Changelog for more details.
To aid in this process there is a script called suggest_backports.py at
https://gist.github.com/embray/4497178. The script is not perfect and still
needs a little work, but it will get most of the work done. For example, if
the current bug fix branch is called ‘v0.2.x’ run it like so:
$ suggest_backports.py astropy astropy v0.2.x -f backport.sh
This will search GitHub for all issues assigned to the next bug fix release
milestone that’s associated with the given bug fix branch (‘v0.2.2’ for
example), find the commits that fix those issues, and will generate a shell
script called backport.sh containing all the git cherry-pick commands
to backport all those fixes.
The suggest_backports.py script will typically take a couple minutes to
run, but once it’s done simply execute the generated script from within your
local clone of the Astropy repository:
This will checkout the appropriate bug fix branch (‘v0.2.x’ in this example),
do a git pull upstream v0.2.x to make sure it’s up to date, and then start
doing cherry-picks into the bug fix branch.
Note
As discussed earlier, cherry-pick may result in merge conflicts. If this
occurs, the backport.sh script will exit and the conflict should be
resolved manually, followed by running git commit. To resume the
backport.sh script after the merge conflict, it is currently necessary
to edit the script to either remove or comment out the git cherry-pick
commands that already ran successfully.
The author of the script hopes to improve it in the future to add
git rebase like functionality, such that running
backport.sh --continue or backport.sh --skip will be possible in
such cases.
Warning
It has also been noted that the suggest_backports.py script is not
perfect, and can either miss issues that need to be backported, and in some
cases can report false positives.
It’s always a good idea before finalizing a bug fix release to look on
GitHub through the list of closed issues in the release milestone and check
that each one has a fix in the bug fix branch. Usually a quick way to do
this is for each issue to run:
$ git log --oneline <bugfix-branch> | grep #<issue>
Most fixes will mention their related issue in the commit message, so this
tends to be pretty reliable. Some issues won’t show up in the commit log,
however, as their fix is in a separate pull request. Usually GitHub makes
this clear by cross-referencing the issue with its PR. A future version
of the suggest_backports.py script will perform this check
automatically.
Finally, not all issues assigned to a release milestone need to be fixed before
making that release. Usually, in the interest of getting a release with
existing fixes out within some schedule, it’s best to triage issues that won’t
be fixed soon to a new release milestone. If the upcoming bug fix release is
‘v0.2.2’, then go ahead and create a ‘v0.2.3’ milestone and reassign to it any
issues that you don’t expect to be fixed in time for ‘v0.2.2’.
Creating a GPG Signing Key and a Signed Tag
One of the main steps in performing a release is to create a tag in the git
repository representing the exact state of the repository that represents the
version being released. For Astropy we will always use signed tags: A
signed tag is annotated with the name and e-mail address of the signer, a date
and time, and a checksum of the code in the tag. This information is then
signed with a GPG private key and stored in the repository.
Using a signed tag ensures the integrity of the contents of that tag for the
future. On a distributed VCS like git, anyone can create a tag of Astropy
called “0.1” in their repository–and where it’s easy to monkey around even
after the tag has been created. But only one “0.1” will be signed by one of
the Astropy project coordinators and will be verifiable with their public key.
Generating a public/private key pair
Git uses GPG to created signed tags, so in order to perform an Astropy release
you will need GPG installed and will have to generated a signing key pair.
Most *NIX installations come with GPG installed by default (as it is used to
verify the integrity of system packages). If you don’t have the gpg
command, consult the documentation for your system on how to install it.
For OSX, GPG can be installed from MacPorts using sudo port install gnupg.
To create a new public/private key pair, simply run:
This will take you through a few interactive steps. For the encryption
and expiry settings, it should be safe to use the default settings (I use
a key size of 4096 just because what does a couple extra kilobytes
hurt?) Enter your full name, preferably including your middle name or
middle initial, and an e-mail address that you expect to be active for a
decent amount of time. Note that this name and e-mail address must match
the info you provide as your git configuration, so you should either
choose the same name/e-mail address when you create your key, or update
your git configuration to match the key info. Finally, choose a very good
pass phrase that won’t be easily subject to brute force attacks.
If you expect to use the same key for some time, it’s good to make a backup of
both your public and private key:
$ gpg --export --armor > public.key
$ gpg --export-secret-key --armor > private.key
Back up these files to a trusted location–preferably a write-once physical
medium that can be stored safely somewhere. One may also back up their keys to
a trusted online encrypted storage, though some might not find that secure
enough–it’s up to you and what you’re comfortable with.
Add your public key to a keyserver
Now that you have a public key, you can publish this anywhere you like–in your
e-mail, in a public code repository, etc. You can also upload it to a
dedicated public OpenPGP keyserver. This will store the public key
indefinitely (until you manually revoke it), and will be automatically synced
with other keyservers around the world. That makes it easy to retrieve your
public key using the gpg command-line tool.
To do this you will need your public key’s keyname. To find this enter:
This will output something like:
/path/to/.gnupg/pubring.gpg
---------------------------------------------
pub 4096D/1234ABCD 2012-01-01
uid Your Name <your_email>
sub 4096g/567890EF 2012-01-01
The 8 digit hex number on the line starting with “pub”–in this example the
“1234ABCD” unique keyname for your public key. To push it to a keyserver
enter:
$ gpg --send-keys 1234ABCD
But replace the 1234ABCD with the keyname for your public key. Most systems
come configured with a sensible default keyserver, so you shouldn’t have to
specify any more than that.
Create a tag
Now test creating a signed tag in git. It’s safe to experiment with this–you
can always delete the tag before pushing it to a remote repository:
$ git tag -s v0.1 -m "Astropy version 0.1"
This will ask for the password to unlock your private key in order to sign
the tag with it. Confirm that the default signing key selected by git is the
correct one (it will be if you only have one key).
Once the tag has been created, you can verify it with:
This should output something like:
object e8e3e3edc82b02f2088f4e974dbd2fe820c0d934
type commit
tag v0.1
tagger Your Name <your_email><PHONE_NUMBER> -0400
Astropy version 0.1
gpg: Signature made Fri 15 Jun 2012 12:59:04 PM EDT using DSA key ID 0123ABCD
gpg: Good signature from "Your Name <your_email>"
You can use this to verify signed tags from any repository as long as you have
the signer’s public key in your keyring. In this case you signed the tag
yourself, so you already have your public key.
Note that if you are planning to do a release following the steps below, you
will want to delete the tag you just created, because the release script does
that for you. You can delete this tag by doing:
Creating a MacOS X Installer on a DMG
The bdist_dmg command can be used to create a .dmg disk image for
MacOS X with a .pkg installer. In order to do this, you will need to
ensure that you have the following dependencies installed:
To create a .dmg file, run:
python setup.py bdist_dmg
Note that for the actual release version, you should do this with the Python
distribution from python.org (not e.g. MacPorts, EPD,
etc.). The best way to ensure maximum compatibility is to make sure that
Python and Numpy are installed into /Library/Frameworks/Python.framework
using the latest stable .dmg installers available for those packages. In
addition, the .dmg should be build on a MacOS 10.6 system, to ensure
compatibility with 10.6, 10.7, and 10.8.
Before distributing, you should test out an installation of Python, Numpy, and
Astropy from scratch using the .dmg installers, preferably on a clean
virtual machine.


CSS Concepts
Relative, absolute, fixed, and static positioning
September 26, 2015
What are the differences between relative, absolute, fixed, and static positioning?
The position values could get a little confusing. I was confused my first time using the values. I'm going to try my best and explain what each one does. The relative position places the element in relation to its normal position. So if we were to apply top, bottom, right, left to the element along with position: relative, it will be adjusted away from the normal position.So it'll move from A --> B. Once you have adjusted the element with relative positioning, other elements won't be able to fit into any whitespace (empty space) the element takes up.
.randomclass { position: relative; top: 0; bottom: 0; right: 10px; left: 0;}The above code will place the elements with the class (randomclass) in a position relative to the original and move it away 10px to the right.
Absolute position is placed at a specific position in relation to the closest element. The position also has the ability to move along with the page if there are no positioned elements (position elements includes everything except static) before it.
.randomclass { position:absolute; left: 5px; top: 50px; }The above code will move the element with the class (randomclass) to the LEFT 5px and TOP 50px. It can move the element anywhere you want to.
A fixed position stays in the same place throughout the entire website. If you created a navigation bar and set it to fixed, it will follow you as you scroll down the page.
.randomclass {position: fixed; bottom:0; border: 1px solid black; }This sets the element in a fixed position on the bottom with a 1px solid lined black border.
The default position is static. This position isn't affected by the top, bottom, right, left properties. Static is positioned to the flow of the page. Top to bottom from the left.


Victoria Grizzlies snap home losing streak
by Cleve Dheensaw
VICTORIA 6
MERRITT 3
It is a tradition, particularly in sports in Commonwealth countries, to award a wooden spoon to the last-place team in a competition or season.
The practice is not as well known in this neck of the Commonwealth. If it was, Saturday night’s B.C. Hockey League game at The Q Centre might have been dubbed the wooden-spoon derby.
With 16 of the 17 teams qualifying, it’s hard to miss the BCHL playoffs. The race for that dubious honour of being the odd team out might come down to the Merritt Centennials, West Kelowna Warriors or Victoria Grizzlies, who trail at the bottom of the table.
Two of those stragglers met in Colwood on Saturday with the Grizzlies (8-19) winning the battle to try to avoid the wooden spoon with a 6-3 victory over the Centennials (5-15-1). The result snapped an eight-game home losing streak for the Grizzlies.
Victoria came into the game having scored only nine goals in its past eight games, but busted out of that scoring slump on two goals each by Cody Monds and Henri Schreifels, with the others coming from Isack Bandu and captain Marty Westhaver.
This is all new territory for the Grizzlies, who have spent more time in recent seasons hovering near the top of the BCHL Island Division than floundering at the foot of the table. That’s what having players such as 2019 NHL first-round draft pick Alex Newhook does for you.
But Newhook and other NHL draft picks from last year’s team — Alex Campbell (Nashville Predators), Carter Berger (Florida Panthers) and Riley Hughes (New York Rangers) — have all moved on.
The Grizzlies are now young and in a rebuilding phase.
Joe Howe, committed to NCAA Div. 1 Cornell Big Red, made 36 saves in goal for the Grizzlies on Saturday to be named game second star behind Monds.
The Grizzlies got 24 shots on Cents’ goaltender Tanner Marshall. Westhaver and Monds had three point-nights while game third-star and blueliner Jake Veilleux added two assists.
Talon Zakall led the Centennials with a goal and assist.
The Grizzlies next play Friday and next Saturday at Powell River against the Kings.


Pitch is the main heading group that usually appears right below the header.
Call to action is a component usually located right above the footer.
Preloaders come in two size, and two colour variations.


NEWS.md
fredr_docs()
now accepts no arguments and just opens https://api.stlouisfed.org/docs/fred/ in a web browser (#75). Note: This is technically a breaking change so we slightly abuse semantic versioning by incrementing the package version from 1.0.0 to 1.1.0.fredr_requests()
now accepts parameter retry_times
parameter indicating maximum number of times request is made in the event of a non-200 response. Default is 10.tag_names
in fredr_tags_series()
.tests/testthat
(#73)Initial release for CRAN. All endpoint functions for the FRED API are now implemented as functions in fredr.
fredr()
-> fredr_request()
(#46)fredr_series()
-> fredr_series_observations()
(alias: fredr()
) (alias: fredr()
) now returns a tibble (with observation date, series ID, and values columns) instead of a time series object (#46, #49).dplyr
and xts
(#9).fred_set_key()
no longer modifies .Renviron
. User is encouraged to manually change .Renviron
to persistently set FRED API key (#15).fredr_search()
into
fredr_series_search_text()
(search for series by text description)fredr_series_search_text()
(search for series)fredr_series_search_tags()
(search for series tags)fredr_series_search_related_tags()
(search for related tags)Categories (#21)
fredr_category()
Get a FRED categoryfredr_category_children()
Get the child categories for a specified FRED parent categoryfredr_category_related()
Get the related categories for a FRED category.fredr_category_related_tags()
Get the related FRED tags within a categoryfredr_category_series()
Get the series in a categoryfredr_category_tags()
Get the FRED tags for a categoryReleases (#22)
fredr_release()
Get a release of economic datafredr_release_dates()
Get release dates for a single release of economic datafredr_release_related_tags()
Get the related FRED tags for one or more FRED tags within a releasefredr_release_series()
Get the series on a release of economic datafredr_release_sources()
Get the sources for a release of economic datafredr_release_tables()
Get release table trees for a given releasefredr_release_tags()
Get the FRED tags for a releasefredr_releases()
Get all releases of economic datafredr_releases_dates()
Get release dates for all releases of economic data.Series (#23)
fredr_series()
Return basic information for a FRED series.fredr_series_categories()
Get the categories for a FRED seriesfredr_series_release()
Get the release for a FRED seriesfredr_series_tags()
Get the tags for a FRED seriesfredr_series_updates()
Get a set of recently updated FRED seriesfredr_series_vintagedates()
Get the data vintage dates for a FRED seriesSources (#24)
fredr_source()
Get a source of economic datafredr_source_releases()
Get the releases for a sourcefredr_sources()
Get all sources of economic dataTags (#25)
fredr_tags()
Get FRED series tagsfredr_related_tags()
Get related FRED tags given one or more tagsfredr_tags_series()
Find FRED series matching tag namesfredr
combines tools like dplyr
and httr
to provide a flexible but powerful wrapper for the FRED API.
fredr_search()
and fredr_series()
for most commonly used FRED API features.fredr()
api_docs()


Key Points
- While modules enable the developer to break a complex app into several simple parts, composition enables them to be stitched back together.
- There are two types of composition in Durandal: Object Composition and Visual Composition.
- Use the compose binding to achieve Visual Composition.
- Combine observables with the compose binding to achieve dynamically changing composition.
If you have read the section on modules, you are already familiar with object composition. For example, if you have two modules: A and B. If module B requires module A, then you have used a very basic form of object composition. This is nothing unique to Durandal, but is provided entirely by the AMD mechanism via RequireJS. By leveraging object and function modules with declarative module dependencies, you can implement object modularization and composition in a way that will help you to easily solve some very complex problems.
Visual compositon allows you to break down your views into re-usable components and to connect them with their composed, object counterparts. This functionality is a central and unique feature of Durandal and is provided by the Composition Module. While you can use the composition module directly to achieve this in code, the most common way of leveraging it will be through the compose binding. If you create widgets or use modal dialogs, you will also be leveraging it indirectly. In fact, everything you see presented in the browser's view is run through Durandal's composition pipeline.
Let's see how composition works, by first looking at app startup. Here's some code from a stripped down main.js file:
define(function(require) { var app = require('durandal/app'); app.start().then(function () { app.adaptToDevice(); app.setRoot('shell', 'entrance'); }); });
Notice the call to setRoot. This actually invokes the composition engine. What is the result?
The result is that your application's shell (main layout/window/etc) is visually composed into the document. Now lets take a look at how we can do some basic visual composition inside of the shell view. Have a look at this markup:

Here we are using the compose binding to inject a view. The composition system will locate 'views/header.html' and inject it into the DOM inside the div. The header html view will be data-bound against the existing context (the shell module) since it's an explicit view composition, without a module. So, how do we specify that header actually has it's own view and module? Like this:

When there is no view extension (according to the view engine) then the composition engine interprets this as a module Id. In this case, it will require the 'viewmodels/header' module and then locate it's view (according to convention). The module and the view will be bound and the view will be injected into the div.
This is all fine for construction of static components, but what about dynamic composition? Well, the compose binding can take an observable, like so:

Imagine that your shell module looks like this:
define(function(require) { return { activeScreen:ko.observable() }; });
Now, the compose binding queries the observable for its value. Here's a few things that could happen, depending on the value of the observable:
The important thing to remember in this case is that this is an observable. So any time your activeScreen property changes, the composition engine will re-compose that part of the DOM. This enables extremely powerful dynamic, changing composition of any part of the dom simply through data-binding. There's lots more the composition engine can do. To dig in deeper have a look at the reference documentation and study the sample and starter kit.


Across: 5. Artist, Turner, captures start of a curving movement (3) 8. Solid hold on prey? (10) 9. Eager to go back after silver (4) 10. Musician’s boy’s cat (3) 11. Blocked one politician because black!? (10) 14. Food may be an afterthought for a scholar (4) 15. Worker is right off drink! (3) 16. Queen’s servant gets in money for Security (10) 20. Annoy the French after Bible study (4) 21. Morsel left out for literary keeper (7) 22. Throw out drugs when running away (7) 24. Northumbrian gold returned by old fiddler (4) 25.  Number forty-nine gets nothing! (3) 30. Good man comes by piece of information (4) 31. Sailor’s social worker gets girl to dance (10) 35. Mr Wallach starts eating live insects! (3) 36. Bighead managed to get cereal (4) 37. Sadness of host without spirit on an island (10) 38. Fix this match? (3) Down: 1. Body fashion? (4) 2,3. Pianist shares my confusion (4 4) 3. see 2 4. T-tease a French official (7) 5. Men ate bull stew before the war (10) 6. Flighty beauty in London (10) 7. One cruel PC developed obesity (10) 11. Devil beheaded solicitor! (3) 12. Mean father may be right! (3) 13. Resort not in Spain (3) 17. Real men, yet rather basic! (10) 18. Rebel can’t mix with Tom and Len (10) 19. I work out with mortal men for 90 minutes? (6 4) 23. A surreal new composition gets Rex going usually (2 1 4) 26. Flyer gets hit! (3) 27. I will be sick! (3) 28. Body of water located east in South Africa (3) 32. At home in Tyneside before 10 (4) 33. Repeat part of the Choral Symphony (4) 34. Limply throw away politician’s flower (4)


Aaron Jacobson
Home
Resume
Portfolio
Photos
Code
Contact
Home
Resume
Portfolio
Photos
Code
Contact
Red Laser
Green and Violet Laser
Laser on Water
Laser Cloud
Light Painting
Light Painting
Laser pointers
Red Lasers
Lasers and Water


ehcache集群配置terracotta
- ehcache for maven conf
<dependency>
<groupId>org.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>${ehcache.version}</version>
</dependency>
<dependency>
<groupId>org.ehcache</groupId>
<artifactId>ehcache-clustered</artifactId>
<version>${ehcache.version}</version>
</dependency>
- tc-config.xml (ehcache3.4.0)版本已经被合并了里面包含
terracotta
<?xml version="1.0" encoding="UTF-8"?>
<tc-config xmlns="http://www.terracotta.org/config"
xmlns:ohr="http://www.terracotta.org/config/offheap-resource">
<!--
This is the default Terracotta server configuration file for the Ehcache kit.
It defines a single offheap resource of 512MB to be used for caching data.
It also defines a single server, but you can add another one to benefit from high availability.
-->
<plugins>
<config>
<ohr:offheap-resources>
<ohr:resource name="main" unit="MB">512</ohr:resource>
</ohr:offheap-resources>
</config>
</plugins>
<servers>
<server host="<IP_ADDRESS>" name="s1">
<!--
Indicates the location for logs files - %H will resolve to user home directory.
Note that relative path will be resolved from the location of this configuration file.
-->
<logs>/home/hadmin/data/logs/ehcache/ehcache-server/terracotta-logs-s1</logs>
<!--
This port is used by clients to communicate to the server.
Its value is actually the default one and is thus omitted.
-->
<tsa-port>9410</tsa-port>
<!--
This port is used for server to server communication.
Its value is actually the default one and is thus omitted.
-->
<tsa-group-port>9430</tsa-group-port>
</server>
<server host="<IP_ADDRESS>" name="s2">
<!--
Indicates the location for logs files - %H will resolve to user home directory.
Note that relative path will be resolved from the location of this configuration file.
-->
<logs>/home/hadmin/data/logs/ehcache/ehcache-server/terracotta-logs-s2</logs>
<!--
This port is used by clients to communicate to the server.
Its value is actually the default one and is thus omitted.
-->
<tsa-port>9410</tsa-port>
<!--
This port is used for server to server communication.
Its value is actually the default one and is thus omitted.
-->
<tsa-group-port>9430</tsa-group-port>
</server>
<!--
Below a sample server definition that will give HA to the cluster if run on a different host.
Servers know how to communicate between each others because each version of the config file on each host
will list all servers in it.
-->
<!--<server host="otherhost" name="other-server">-->
<!--<logs>logs</logs>-->
<!--<tsa-port>9410</tsa-port>-->
<!--</server>-->
<!--
Indicates how much time a server taking over after a failure in an active will wait
to allow existing clients to reconnect. The time unit is seconds.
-->
<client-reconnect-window>120</client-reconnect-window>
</servers>
</tc-config>
-
以上的配置文件为两个节点
-
分别在两个节点上运行相应命令。
# 1
nohup ./bin/start-tc-server.sh -f conf/tc-config.xml -n s1 &
# 2
nohup ./bin/start-tc-server.sh -f conf/tc-config.xml -n s2 &
-
这样两台基本的Ehcache 服务集群就搭建成功了。
-
文章写的比较着急，不忙了在继续整理，望理解。
-
测试代码
package todcloud.utils.ehcache;
/**
* Created by zhangjianxin on 2017/12/4.
* Github Breakeval13
* blog firsh.me
*/
import java.net.URI;
import org.ehcache.Cache;
import org.ehcache.CacheManager;
import org.slf4j.Logger;
import static java.net.URI.create;
import static org.ehcache.clustered.client.config.builders.ClusteredResourcePoolBuilder.clusteredDedicated;
import static org.ehcache.clustered.client.config.builders.ClusteringServiceConfigurationBuilder.cluster;
import static org.ehcache.config.builders.CacheConfigurationBuilder.newCacheConfigurationBuilder;
import static org.ehcache.config.builders.CacheManagerBuilder.newCacheManagerBuilder;
import static org.ehcache.config.builders.ResourcePoolsBuilder.heap;
import static org.ehcache.config.units.MemoryUnit.MB;
import static org.slf4j.LoggerFactory.getLogger;
public class ClusteredProgrammatic {
private static final Logger LOGGER = getLogger(ClusteredProgrammatic.class);
public static void main(String[] args) {
LOGGER.info("Creating clustered cache manager");
final URI uri = create("terracotta://<IP_ADDRESS>:9410/s1");
try (CacheManager cacheManager = newCacheManagerBuilder()
.with(cluster(uri).autoCreate().defaultServerResource("main"))
.withCache("basicCache",
newCacheConfigurationBuilder(Long.class, String.class,
heap(100).offheap(1, MB).with(clusteredDedicated(512, MB))))
.build(true)) {
Cache<Long, String> basicCache = cacheManager.getCache("basicCache", Long.class, String.class);
LOGGER.info("Putting to cache");
// basicCache.put(100L, "da one!");
// basicCache.put(1L, "da one1L!");
System.out.println(basicCache.get(1L));
LOGGER.info("Closing cache manager");
}
LOGGER.info("Exiting");
}
}


The code assumes that the following 'time' constants are in a increasing sequence.
The code assumes that the following 'time' constants are in a increasing sequence.
| Member Name | Description |
|---|---|
| InvalidRollPoint | Roll the log not based on the date |
| TopOfMinute | Roll the log for each minute |
| TopOfHour | Roll the log for each hour |
| HalfDay | Roll the log twice a day (midday and midnight) |
| TopOfDay | Roll the log each day (midnight) |
| TopOfWeek | Roll the log each week |
| TopOfMonth | Roll the log each month |
Namespace: log4net.Appender
Assembly: log4net (in log4net.dll)


Reports annotations on the record components that have no effect. This may happen in two cases:
Example:
@Target(ElementType.METHOD) @interface A { } // The annotation will not appear in bytecode at all, // as it should be propagated to the accessor but accessor is explicitly defined record R(@A int x) { public int x() { return x; } }
New in 2021.1


QuantConnect's LEAN engine manages your portfolio and data feeds, letting you focus on your algorithm strategy and execution. Data is piped into your strategy via event handlers, upon which you can place trades. We automatically provide basic portfolio management and fill modeling underneath the hood. This is provided by the $[QCAlgorithm,T:QuantConnect.Algorithm.QCAlgorithm] base class.
All algorithms extend $[QCAlgorithm,T:QuantConnect.Algorithm.QCAlgorithm], which provides some key helper properties for you to use: Security Manager, Portfolio Manager, Transactions Manager, Notification Manager, and Scheduling Manager. Along with hundreds of helper methods to make the API easy to use. We'll go into more detail in the next few sections.
The $[Securities,P:QuantConnect.Algorithm.QCAlgorithm.Securities] property
is a dictionary of Security objects. Each asset (equity, forex pair, etc) in your algorithm has a security object. All the models for a security live on these objects:
e.g.
Securities["IBM"].FeeModel
or Securities["IBM"].Price
.
self.Securities["IBM"].FeeModel
or self.Securities["IBM"].Price
.
$[Portfolio,P:QuantConnect.Algorithm.QCAlgorithm.Portfolio] is a dictionary of SecurityHolding classes.
These classes track the individual portfolio items profit and losses, fees, and quantity held. e.g.
Portfolio["IBM"].LastTradeProfit
self.Portfolio["IBM"].LastTradeProfit
.
Other helpers like $[Transactions,P:QuantConnect.Algorithm.QCAlgorithm.Transactions], $[Schedule,P:QuantConnect.Algorithm.QCAlgorithm.Schedule], $[Notify,P:QuantConnect.Algorithm.QCAlgorithm.Notify], and $[Universe,P:QuantConnect.Algorithm.QCAlgorithm.Universe] have their own helper methods, which we'll explain in the following sections.
public class QCAlgorithm { SecurityManager Securities; //Array of Security objects. SecurityPortfolioManager Portfolio; // Array of SecurityHolding objects SecurityTransactionManager Transactions; // Transactions helper ScheduleManager Schedule; // Scheduling helper NotificationManager Notify; //Email, SMS helper UniverseManager Universe; // Universe helper //Set up Requested Data, Cash, Time Period. public virtual void Initialize() { ... }; //Event Handlers: public virtual OnData(Slice data) { ... }; public virtual OnDividend() { ... }; public virtual OnEndOfDay() { ... }; public virtual OnEndOfAlgorithm() { ... }; //Helpers... public SimpleMovingAverage SMA(); }
def QCAlgorithm { self.Securities; # Array of Security objects. self.Portfolio; # Array of SecurityHolding objects self.Transactions; # Transactions helper self.Schedule; # Scheduling helper self.Notify; # Email, SMS helper self.Universe; # Universe helper # Set up Requested Data, Cash, Time Period. def Initialize: # Other Event Handlers: def OnData(self, slice): def OnEndOfDay(self, symbol): def OnEndOfAlgorithm(): # Indicator Helpers def SMA(): }


By Donald Davis
Narrated by Donald Davis
Published by August House Audio in 2004<PHONE_NUMBER>069)
English, 56 minutes, Unabridged
MP3 64 kbps, 29.81 MB, 11 file(s)
Uploaded by henkin
1 seeder, 0 leechers, 2 snatches, 0 comments, 1 bookmark
If you download this torrent, your ratio will be 2.275.
Files
| Filename | Size |
|---|---|
| 01 The Family Doctor.mp3 | 1.18 MB |
| 02 Time To Get Our Typhoid Shots.mp3 | 1.65 MB |
| 03 Mama Comes To School.mp3 | 1.53 MB |
| 04 Time To Run.mp3 | 6.57 MB |
| 05 Dr. York Arrives.mp3 | 4.62 MB |
| 06 Sick Again.mp3 | 2.30 MB |
| 07 Sent To A Specialist.mp3 | 1.07 MB |
| 08 What's A Nun.mp3 | 1.56 MB |
| 09 At St. Joseph's.mp3 | 3.29 MB |
| 10 The Operation.mp3 | 3.48 MB |
| 11 Easter Morning.mp3 | 2.56 MB |
Description
By the time a child is seven or so, he learns that there are certain promises a parent may not keep: "We'll get a puppy soon". and "This won't hurt a bit!"
In rural North Carolina in 1951, despite parental reassurances, a typhoid shot hurt. It hurt even more when the children saw who would be administering the shot: Miss Winnie, a large, dictatorial nurse who had been "especially built by the nursing school so she would never blow away in a hard wind".
In this hilarious epic tale, our young hero learns three valuable lessons: avoiding pain only heightens it, a mother's wrath can hurt worse than a shot, and growing up sometimes involves choosing the lesser of two evils.
In "Tonsils," young Davis comes face-to-face with a creature known as a "nurse-nun" when he has to get his tonsils removed. This humorous account of a tonsillectomy performed on Good Friday in a Catholic hospital pops with Davis' usual firecracker wit and humor.
Comments
No comments found.


Members
Payments
Draw Winners
Reports
Last Draw
-
Prize
Membership Number
Name
Town
Prize
Membership Number
Name
Town
Notifications Panel


Lorem ipsum dolor?
Lorem ipsum dolor.
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Voluptatem, soluta!
Click to get your gift today
wb_sunny
Enterprise
Premium
Lorem ipsum dolor.
Starter
Lorem ipsum dolor.
explore today
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
10€
perfect
title
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Ad, blanditiis esse eum eveniet iste minima.
Lorem ipsum dolor sit.
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Ab, corporis, cum dolor dolores eum eveniet illum ipsam omnis placeat praesentium quod ratione repudiandae rerum, similique soluta ullam ut velit vitae!
turned_in_not
Alien's Card
Surname
xerxes
Given names
confucius
Date of expiry
AAAA/MM/DD
Date of issue
AAAA/MM/DD
remarks
pikachu - pokemon
turned_in
By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest.
Lore6555<<<labori osam25 64645454 olorum 4658456 45867 46857 48547a liaseiu smoles <<
4
3
2
1


module ActiveRecord::AttributeMethods::ClassMethods
Public Instance Methods
attribute_method?(attribute)
click to toggle source
Returns true
if attribute
is an attribute method
and table exists, false
otherwise.
class Person < ActiveRecord::Base end Person.attribute_method?('name') # => true Person.attribute_method?(:age=) # => true Person.attribute_method?(:nothing) # => false
Calls superclass method
# File lib/active_record/attribute_methods.rb, line 174 def attribute_method?(attribute) super || (table_exists? && column_names.include?(attribute.to_s.sub(/=$/, ''))) end
attribute_names()
click to toggle source
Returns an array of column names as strings if it's not an abstract class and table exists. Otherwise it returns an empty array.
class Person < ActiveRecord::Base end Person.attribute_names # => ["id", "created_at", "updated_at", "name", "age"]
# File lib/active_record/attribute_methods.rb, line 186 def attribute_names @attribute_names ||= if !abstract_class? && table_exists? column_names else [] end end
class_method_defined_within?(name, klass, superklass = klass.superclass)
click to toggle source
# File lib/active_record/attribute_methods.rb, line 153 def class_method_defined_within?(name, klass, superklass = klass.superclass) # :nodoc if klass.respond_to?(name, true) if superklass.respond_to?(name, true) klass.method(name).owner != superklass.method(name).owner else true end else false end end
column_for_attribute(name)
click to toggle source
Returns the column object for the named attribute. Returns nil if the named attribute does not exist.
class Person < ActiveRecord::Base end person = Person.new person.column_for_attribute(:name) # the result depends on the ConnectionAdapter # => #<ActiveRecord::ConnectionAdapters::Column:0x007ff4ab083980 @name="name", @sql_type="varchar(255)", @null=true, ...> person.column_for_attribute(:nothing) # => nil
# File lib/active_record/attribute_methods.rb, line 206 def column_for_attribute(name) column = columns_hash[name.to_s] if column.nil? ActiveSupport::Deprecation.warn(" `#column_for_attribute` will return a null object for non-existent columns in Rails 5. Use `#has_attribute?` if you need to check for an attribute's existence. ".squish) end column end
dangerous_class_method?(method_name)
click to toggle source
A class method is 'dangerous' if it is already (re)defined by Active Record, but not by any ancestors. (So 'puts' is not dangerous but 'new' is.)
# File lib/active_record/attribute_methods.rb, line 149 def dangerous_class_method?(method_name) BLACKLISTED_CLASS_METHODS.include?(method_name.to_s) || class_method_defined_within?(method_name, Base) end
instance_method_already_implemented?(method_name)
click to toggle source
Raises a ActiveRecord::DangerousAttributeError
exception when
an Active Record method is defined in the model, otherwise
false
.
class Person < ActiveRecord::Base def save 'already defined by Active Record' end end Person.instance_method_already_implemented?(:save) # => ActiveRecord::DangerousAttributeError: save is defined by ActiveRecord Person.instance_method_already_implemented?(:name) # => false
Calls superclass method
# File lib/active_record/attribute_methods.rb, line 113 def instance_method_already_implemented?(method_name) if dangerous_attribute_method?(method_name) raise DangerousAttributeError, "#{method_name} is defined by Active Record. Check to make sure that you don't have an attribute or method with the same name." end if superclass == Base super else # If ThisClass < ... < SomeSuperClass < ... < Base and SomeSuperClass # defines its own attribute method, then we don't want to overwrite that. defined = method_defined_within?(method_name, superclass, Base) && ! superclass.instance_method(method_name).owner.is_a?(GeneratedAttributeMethods) defined || super end end


Patrick Hand is a font based on the designer's own handwriting. It is developed to bring an impressive and useful handwriting effect to your texts. This is the Small Caps sister family.
It has all the basic latin characters as well as most of the latin extended ones. It also includes some fancy glyphs like heavy quotation marks and the floral heart! Ligatures, small caps and old style numbers are available as OpenType features in the download of the regular Patrick Hand family.
Updated 2019-03: Updated to latest upstream release, fixing 'fi' ligature.


Personal Data
Surname
First Name
Middle Name
You are:
male
female
Age
Country of Residence
WonderLand
NeverLand
SadnessLand
City :
Ryazan
Moscow
Photography
Title
Web Master
Database Administrator
Computer-aided designer
Economic Planning
Management accounying
Badgetting and planning
Salary
Contact Information
Site
Email
Phone
Password
Отправить
Сбросить


movies
Test One
Your browser does not support the video tag.
Test Two
Your browser does not support the video tag.
Update


About us
Located in the heart of the city Tree House brings for market what's the beat for you pet.
Founded in 1987, Tree House is prominence in the city already and wins new cotumers every day.
Our mission is: "Delivery care and quality of life for our costumers through products and services for pets ".
We have experienced professionals and tuned to market trends.
The services has standard of excellence and care, ensuring quality and satisfaction of our customers.
Our Address
Come and see the comfort of our store!
Benefits
- Personalized Service
- Family environment
- Prime location
- Specialized professionals


JavaScript is disabled on your browser.
Skip navigation links
Overview
Package
Class
Tree
Deprecated
Index
Help
Prev
Next
Frames
No Frames
All Classes
Hierarchy For Package controller
Package Hierarchies:
All Packages
Class Hierarchy
java.lang.Object
controller.
AirportUtils
controller.
DataParserBuilder
controller.
DataParserBuilder.CSVBuilder
controller.
DataParserBuilder.CSVBuilder.CSVTypeBuilder
controller.
DataParserBuilder.XMLBuilder
controller.
DataParserBuilder.XMLBuilder.XMLTypeBuilder
controller.
DataUtils
controller.
EarthQuakeUtils
controller.
EarthQuakeUtils.DepthLessThanFilter
(implements controller.
EarthQuakeUtils.EarthQuakeFilter
)
controller.
EarthQuakeUtils.DepthMoreThanFilter
(implements controller.
EarthQuakeUtils.EarthQuakeFilter
)
controller.
EarthQuakeUtils.DepthRangeFilter
(implements controller.
EarthQuakeUtils.EarthQuakeFilter
)
controller.
EarthQuakeUtils.ExactDepthFilter
(implements controller.
EarthQuakeUtils.EarthQuakeFilter
)
controller.
EarthQuakeUtils.ExactMagnitudeFilter
(implements controller.
EarthQuakeUtils.EarthQuakeFilter
)
controller.
EarthQuakeUtils.MagnitudeLessThanFilter
(implements controller.
EarthQuakeUtils.EarthQuakeFilter
)
controller.
EarthQuakeUtils.MagnitudeMoreThanFilter
(implements controller.
EarthQuakeUtils.EarthQuakeFilter
)
controller.
EarthQuakeUtils.MagnitudeRangeFilter
(implements controller.
EarthQuakeUtils.EarthQuakeFilter
)
controller.
MarkerUtils
controller.
SearchUtils
controller.
TestMain
controller.
WorldDataUtils
Interface Hierarchy
java.util.function.Predicate<T>
controller.
EarthQuakeUtils.EarthQuakeFilter
Skip navigation links
Overview
Package
Class
Tree
Deprecated
Index
Help
Prev
Next
Frames
No Frames
All Classes


Session 12 Preparation — Videos, Reading and Quizzes
Instructions:
BEFORE this session, for each of the following videos or reading:
Watch the video (or read the reading), and as you do so,
do the associated quiz in Moodle.
Videos and Reading:
Iterating through a sequence, review
If you think that it would help you, review this video
on iterating through a sequence
[11:35 minutes] that was your introduction to sequences (in a previous Preparation).
Patterns for Iterating Through Sequences
In the previous session's Preparation, you watched the first 9 minutes
of this


There once was a hermit who had two cloaks, one for feast days and the other for everyday. There came one winter a poor man, seeking clothing. However, he held out a loaf of bread and gave it to him, saying. "Take this, for I have no extra clothing to give you." But the poor man kept on weeping and wailing, saying: "Have pity on me." And so the monk, overcome by the poor man's entreaty, went into his cell and pulled off his everyday cloak and gave it to the poor man; but he keep the better one for himself. But later, stricken with remorse, he said to the poor man: "Give me back the cloak that I gave you and take this better one."
Now after the poor man had taken it, he put it on and, going out into the city, sold it to a certain prostitue. And she put it on and came once and again to where that monk was. Now when he saw his own clothing, he recognized it as the one that he used to wear on feast days. He was most grieved and, going into his cell, said: "Truly, what I did did not please God, and he has not accepted my devotion, seeing that my cloak, which I used to wear on feast days, has come into such hands as these, and a mere prostitue wears it."
Indeed, on account of his sorrow he did not eat that day. But that night, when he fell asleep he saw our Lord Jesus Christ, clothed in the garment that he had given the poor man, who had entered his cell and said to him: "Brother, brother." And as he looked, he saw a great light and said: "Who are you, Lord?" And he said to him: "Look at me." But as he stared, he said to him: "Do you recognize this?" He answered: "Even so, Lord: it is my cloak." He said to him: "I am Jesus. Sorrow no more, but rejoice and be of good cheer and give thanks to God. For what you gave to the poor man, I have received." And the monk took great joy in the kindness of our Lord Jesus Christ, who did not allow him to be tormented by his thoughts, but gave him assurance in his word what he had said before, that "what you have done for the least of mine, you have done for me."


Prepare a neatly-formatted file of declarations of variables,
common blocks, and namelist lists, for possible
merging into the source code. The declarations are stored in a file
of the same name as the source code, but with the extension changed to
.dcl.
If no declarations are written to the file, it is deleted to reduce
clutter from empty files.
If input comes from standard input, instead of a named file, then
declarations are written to standard output.
Variables are declared in alphabetical order within each declaration
class and type, with integer variables first, because of their later
possible use in array dimensions.
PARAMETER statements are an exception to the alphabetical order
rule, because the Fortran 77 Standard requires that the expressions
defining parameter values refer only to constants and already-defined
parameter names. This forces the original source file order of such
statements to be preserved in the declaration files.
Explicit declaration of
all
variables is considered good modern programming practice. By using
compiler options to reject undeclared variables, misspelled variable
names (or names extending past column 72) can be caught at compile
time. Explicit declarations also greatly facilitate changing
floating-point precision with filters such as
dtoq(1L),
dtos(1L),
fd2s(1L),
fs2d(1L),
qtod(1L),
and
stod(1L).
These programs are capable of changing types of explicit
floating-point type declarations, intrinsic functions, and constants,
but because they do not carry out rigorous lexical and grammatical
analysis of the Fortran source code, they cannot provide modified type
declarations for undeclared variables.
Default setting = 0, turn-on = 1.
Various options for the form of the declarations file are controlled
by the list, which consists of keywords
separated by commas or colons.
There are three special keywords: all to turn on all the
options, none to turn them all
off, and help to print the list of all the keywords with a brief
explanation of each.
If list is omitted, -makedcls is equivalent to
-makedcls=declarations (i.e. produce the declarations file
using the default options), and
-nomakedcls is equivalent to -makedcls=none.
For compatibility with previous versions of ftnchek, a numeric
form of this setting is also accepted: the list is replaced by
a number which is the sum of the numbers in parentheses beside
the keywords in the following list.
The warning keywords with their meanings are as follows:
- declarations (1):
-
Write a declaration file. (This is implied by any of the other
options, and can be omitted if any other options are given.)
- undeclared-only (2):
-
By default, all variables are included in the declaration file. With
this option, include only
undeclared
variables. This setting is useful if you want to check for undeclared
variables, since Fortran source files with all variables properly
declared will not result in a
.dcl
file.
With this option, common blocks and namelist lists will not be
included in the declaration file, since by their nature they cannot be
undeclared.
- compact (4):
-
The declarations are normally prettyprinted to line up neatly in
common columns, as in the declaration files output by the Extended
PFORT Verifier,
pfort(1L).
This option value selects instead compact output, without column
alignment.
- use-continuation-lines (8):
-
Causes continuation lines to be used where permissible.
The default is to begin a new declaration on each line. This option
is appropriate to use together with compact.
- keywords-lowercase (16):
-
Output Fortran keywords in lowercase, instead of the default
uppercase.
- vars-and-consts-lowercase (32):
-
Output variables and constants in lowercase, instead of the default
uppercase. Character string constants are not affected by this
option.
- exclude-sftran3 (64):
-
Omit declarations of internal integer variables produced by the
SFTRAN3 preprocessor,
xsf3(1L),
as part of the translation of structured Fortran statements to
ordinary Fortran. These variables have six-character names of the
form
NPRddd,
NXdddd,
N2dddd,
and
N3dddd,
where
d
is a decimal digit. Because they are invisible in the SFTRAN3 source
code, and will change if the SFTRAN3 code is modified, such variables
should not be explicitly declared. Instead, they should just assume
the default Fortran INTEGER data type based on their initial letter,
N.
- asterisk-comment (128):
-
Use an asterisk as the comment character; the default is otherwise 'C'.
- comment-char-lowercase (256):
-
Use 'c' instead of 'C' or '*' as the comment character.
- suppress-array-dimensions (512):
-
Suppress dimensioning of arrays in the generated declarations.
This option is for use with code lacking type declarations, to allow
the declaration files to be inserted without change into the code. Since
the code will have dimension statements already, dimensioning the
array variables in the type statements of the declaration file is redundant.
This option should be used only in conjunction with
option 2 = undeclared-only because otherwise any arrays that were
dimensioned in a type statement will lose their dimensioning.
- free-form (1024):
-
Produce declarations in free source form. This mode is automatically
used if the input source is free form. Use this option to produce
declarations in free form even if the input is in fixed form. Free
form declarations are indented only 2 columns instead of 6, use the
exclamation mark as the comment character, and indicate continuation
lines by an ampersand at the end of the line to be continued.
The declaration files contain distinctive comments that mark the start
and end of declarations for each program unit, to facilitate using
text editor macros for merging the declarations back into the source
code.
The ftnchek distribution includes a program, dcl2inc,
which processes declaration files to produce files containing
declarations of all COMMON blocks, in a form suitable for use as
INCLUDE files. See the
dcl2inc(1L)
man page for the details
of its use.
See also: -mkhtml.


Swiss Data Security
Our email service safeguards user data with strict privacy protections and our secure datacenter facility hidden inside a Swiss granite mountain.
End-To-End Encryption
Your emails are automatically end-to-end encrypted inside our email service. Because of this, we cannot decrypt or share your data with third parties.
Private Email Service
No personal information is required to create your secure email account. We don't keep IP logs which can be linked to your username. We take privacy seriously.
Free for everyone
ProtonMail is committed to providing free private email service for everyone with all end-to-end encryption and privacy features and no hidden costs.
Stress-Free Email Provider
Use any device with a modern web browser to access our secure email service. ProtonMail sends and receives email just like regular email providers.
Security With Productivity
Each detail within our secure email service is optimized to help you better read, organize, and send email.
"A new email service being developed by a group from MIT and CERN promises to bring secure, encrypted email to the masses and keep sensitive information away from prying eyes."– Boston Herald
"...[ProtonMail's] security measures are intense: end-to-end encryption and user authentication protocols so rigorous even the creators can't read user emails."- Huffington Post
"ProtonMail hosts its servers in Switzerland... so all user data is protected by strict Swiss privacy laws."- Wall Street Journal
+41 022 575 46 99
1<PHONE_NUMBER>
English Media Inquiries1<PHONE_NUMBER>
| General |<EMAIL_ADDRESS>|
|---|---|
| Media |<EMAIL_ADDRESS>|
For support visit:
https://support.protonmail.ch
For security related discussions:
security@protonmail.ch


2 Chronicles 18:14
And when he was come to the king, the king said unto him, Micaiah, shall we go to Ramothgilead to battle, or shall I forbear?


GOME2_L2_O3MOTO
Variables
The table below lists the variables that are present in the HARP product that results from an ingestion of GOME2_L2_O3MOTO
data.
| field name | type | dimensions | unit | description |
|---|---|---|---|---|
| datetime | double | {time} | [seconds since 2000-01-01] | time of the measurement |
| longitude | double | {time} | [degree_east] | longitude of the measurement |
| latitude | double | {time} | [degree_north] | latitude of the measurement |
| longitude_bounds | double | {time, 4} | [degree_east] | corner longitudes of the measurement |
| latitude_bounds | double | {time, 4} | [degree_north] | corner latitudes of the measurement |
| sensor_solar_zenith_angle | double | {time} | [degree] | solar zenith angle at the sensor |
| solar_zenith_angle | double | {time} | [degree] | solar zenith angle at top of atmosphere |
| viewing_zenith_angle | double | {time} | [degree] | viewing zenith angle at top of atmosphere |
| relative_azimuth_angle | double | {time} | [degree] | relative azimuth angle at top of atmosphere |
| BrO_column_number_density | double | {time} | [molec/cm^2] | BrO column number density |
| BrO_column_number_density_uncertainty | double | {time} | [molec/cm^2] | uncertainty of the BrO column number density |
| BrO_column_number_density_validity | int8 | {time} | [] | quality flags for BrO retrieval |
| H2O_column_density | double | {time} | [kg/m^2] | H2O column mass density |
| H2O_column_density_uncertainty | double | {time} | [kg/m^2] | uncertainty of the H2O column mass density |
| H2O_column_number_density_validity | int8 | {time} | [] | quality flags for H2O retrieval |
| HCHO_column_number_density | double | {time} | [molec/cm^2] | HCHO column number density |
| HCHO_column_number_density_uncertainty | double | {time} | [molec/cm^2] | uncertainty of the HCHO column number density |
| HCHO_column_number_density_validity | int8 | {time} | [] | quality flags for HCHO retrieval |
| NO2_column_number_density | double | {time} | [molec/cm^2] | NO2 column number density |
| NO2_column_number_density_uncertainty | double | {time} | [molec/cm^2] | uncertainty of the NO2 column number density |
| NO2_column_number_density_validity | int8 | {time} | [] | quality flags for NO2 retrieval |
| tropospheric_NO2_column_number_density | double | {time} | [molec/cm^2] | tropospheric NO2 column number density |
| tropospheric_NO2_column_number_density_uncertainty | double | {time} | [molec/cm^2] | uncertainty of the tropospheric NO2 column number density |
| O3_column_number_density | double | {time} | [DU] | O3 column number density |
| O3_column_number_density_uncertainty | double | {time} | [DU] | uncertainty of the O3 column number density |
| O3_column_number_density_validity | int8 | {time} | [] | quality flags for O3 retrieval |
| OClO_column_number_density | double | {time} | [molec/cm^2] | OClO column number density |
| OClO_column_number_density_uncertainty | double | {time} | [molec/cm^2] | uncertainty of the OClO column number density |
| OClO_column_number_density_validity | int8 | {time} | [] | quality flags for OClO retrieval |
| SO2_column_number_density | double | {time} | [DU] | SO2 column number density |
| SO2_column_number_density_uncertainty | double | {time} | [DU] | uncertainty of the SO2 column number density |
| SO2_column_number_density_validity | int8 | {time} | [] | quality flags for SO2 retrieval |
| BrO_column_number_density_amf | double | {time} | [] | BrO air mass factor |
| BrO_column_number_density_amf_uncertainty | double | {time} | [] | uncertainty of the BrO air mass factor |
| H2O_column_number_density_amf | double | {time} | [] | H2O air mass factor |
| H2O_column_number_density_amf_uncertainty | double | {time} | [] | uncertainty of the H2O air mass factor |
| HCHO_column_number_density_amf | double | {time} | [] | HCHO air mass factor |
| HCHO_column_number_density_amf_uncertainty | double | {time} | [] | uncertainty of the HCHO air mass factor |
| NO2_column_number_density_amf | double | {time} | [] | NO2 air mass factor |
| NO2_column_number_density_amf_uncertainty | double | {time} | [] | uncertainty of the NO2 air mass factor |
| tropospheric_NO2_column_number_density_amf | double | {time} | [] | tropospheric NO2 air mass factor |
| tropospheric_NO2_column_number_density_amf_uncertainty | double | {time} | [] | uncertainty of the tropospheric NO2 air mass factor |
| O3_column_number_density_amf | double | {time} | [] | O3 air mass factor |
| O3_column_number_density_amf_uncertainty | double | {time} | [] | uncertainty of the O3 air mass factor |
| OClO_column_number_density_amf | double | {time} | [] | OClO air mass factor |
| OClO_column_number_density_amf_uncertainty | double | {time} | [] | uncertainty of the OClO air mass factor |
| SO2_column_number_density_amf | double | {time} | [] | SO2 air mass factor |
| SO2_column_number_density_amf_uncertainty | double | {time} | [] | uncertainty of the SO2 air mass factor |
| O3_effective_temperature | double | {time} | [] | fitted ozone temperature |
| pressure | double | {time, vertical} | [hPa] | pressure levels |
| HCHO_volume_mixing_ratio_dry_air_apriori | double | {time, vertical} | [ppv] | a priori HCHO volume mixing ratio profile |
| HCHO_column_number_density_avk | double | {time, vertical} | [] | HCHO column averaging kernel |
| NO2_volume_mixing_ratio_dry_air_apriori | double | {time, vertical} | [ppv] | a priori NO2 volume mixing ratio profile |
| NO2_column_number_density_avk | double | {time, vertical} | [] | NO2 column averaging kernel |
| surface_albedo | double | {time} | [] | surface albedo |
| cloud_fraction | double | {time} | [] | cloud fraction |
| cloud_fraction_uncertainty | double | {time} | [] | uncertainty of the cloud fraction |
| cloud_top_pressure | double | {time} | [hPa] | cloud top pressure |
| cloud_top_pressure_uncertainty | double | {time} | [hPa] | uncertainty of the cloud top pressure |
| cloud_top_height | double | {time} | [km] | cloud top height |
| cloud_top_height_uncertainty | double | {time} | [km] | uncertainty of the cloud top height |
| cloud_top_albedo | double | {time} | [] | cloud top albedo |
| cloud_top_albedo_uncertainty | double | {time} | [] | uncertainty of the cloud top albedo |
| cloud_optical_depth | double | {time} | [] | cloud optical depth |
| cloud_optical_depth_uncertainty | double | {time} | [] | uncertainty of the cloud optical depth |
| absorbing_aerosol_index | double | {time} | [] | absorbing aerosol index |
| surface_heigth | double | {time} | [km] | surface height |
| surface_pressure | double | {time} | [hPa] | surface pressure |
| scan_subindex | int8 | {time} | the relative index (0-31) of this measurement within a scan (forward + backward) | |
| scan_direction_type | int8 | {time} | scan direction for each measurement; enumeration values: forward (0), backward (1) | |
| index | int32 | {time} | zero-based index of the sample within the source product |
Ingestion options
The table below lists the available ingestion options for GOME2_L2_O3MOTO
products.
| option name | legal values | description |
|---|---|---|
| detailed_results | BrO, H2O, HCHO, NO2, O3, OClO, SO2 | include additional detailed results for the given species |
Mapping description
The table below details where and how each variable was retrieved from the input product.
| field name | mapping description | |
|---|---|---|
| datetime | path | /GEOLOCATION/Time[]/Day, /GEOLOCATION/Time[]/MillisecondOfDay |
| description | the time values are converted to seconds since 2000-01-01 00:00:00 using time = (Day -<PHONE_NUMBER>) * 86400 + MillisecondOfDay / 1000 | |
| longitude | path | /GEOLOCATION/LongitudeCentre[] |
| latitude | path | /GEOLOCATION/LatitudeCentre[] |
| longitude_bounds | path | /GEOLOCATION/LongitudeA[], /GEOLOCATION/LongitudeB[], /GEOLOCATION/LongitudeC[], /GEOLOCATION/LongitudeD[] |
| description | the corner coordinates are re-arranged in the order B-D-C-A | |
| latitude_bounds | path | /GEOLOCATION/LatitudeA[], /GEOLOCATION/LatitudeB[], /GEOLOCATION/LatitudeC[], /GEOLOCATION/LatitudeD[] |
| description | the corner coordinates are re-arranged in the order B-D-C-A | |
| sensor_solar_zenith_angle | path | /GEOLOCATION/SolarZenithAngleSatCentre[] |
| solar_zenith_angle | path | /GEOLOCATION/SolarZenithAngleCentre[] |
| viewing_zenith_angle | path | /GEOLOCATION/LineOfSightZenithAngleCentre[] |
| relative_azimuth_angle | path | /GEOLOCATION/RelativeAzimuthCentre[] |
| BrO_column_number_density | available | optional |
| path | /TOTAL_COLUMNS/BrO[] | |
| BrO_column_number_density_uncertainty | available | optional |
| condition | CODA product version < 3 | |
| path | /TOTAL_COLUMNS/BrO_Error[], /TOTAL_COLUMNS/BrO[] | |
| description | derived from the relative error in percent as: BrO_Error[] * 0.01 * BrO[] | |
| condition | CODA product version >= 3 | |
| path | /TOTAL_COLUMNS/BrO_Error[] | |
| BrO_column_number_density_validity | available | optional |
| path | /DETAILED_RESULTS/QualityFlags[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘BrO’ | |
| H2O_column_density | available | optional |
| path | /TOTAL_COLUMNS/H2O[] | |
| H2O_column_density_uncertainty | available | optional |
| condition | CODA product version < 3 | |
| path | /TOTAL_COLUMNS/H2O_Error[], /TOTAL_COLUMNS/H2O[] | |
| description | derived from the relative error in percent as: H2O_Error[] * 0.01 * H2O[] | |
| condition | CODA product version >= 3 | |
| path | /TOTAL_COLUMNS/H2O_Error[] | |
| H2O_column_number_density_validity | available | optional |
| path | /DETAILED_RESULTS/QualityFlags[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘H2O’ | |
| HCHO_column_number_density | available | optional |
| path | /TOTAL_COLUMNS/HCHO[] | |
| HCHO_column_number_density_uncertainty | available | optional |
| condition | CODA product version < 3 | |
| path | /TOTAL_COLUMNS/HCHO_Error[], /TOTAL_COLUMNS/HCHO[] | |
| description | derived from the relative error in percent as: HCHO_Error[] * 0.01 * HCHO[] | |
| condition | CODA product version >= 3 | |
| path | /TOTAL_COLUMNS/HCHO_Error[] | |
| HCHO_column_number_density_validity | available | optional |
| path | /DETAILED_RESULTS/QualityFlags[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘HCHO’ | |
| NO2_column_number_density | available | optional |
| path | /TOTAL_COLUMNS/NO2[] | |
| NO2_column_number_density_uncertainty | available | optional |
| condition | CODA product version < 3 | |
| path | /TOTAL_COLUMNS/NO2_Error[], /TOTAL_COLUMNS/NO2[] | |
| description | derived from the relative error in percent as: NO2_Error[] * 0.01 * NO2[] | |
| condition | CODA product version >= 3 | |
| path | /TOTAL_COLUMNS/NO2_Error[] | |
| NO2_column_number_density_validity | available | optional |
| path | /DETAILED_RESULTS/QualityFlags[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘NO2’ | |
| tropospheric_NO2_column_number_density | available | optional |
| condition | CODA product version < 2 | |
| path | /TOTAL_COLUMNS/NO2_Trop[] | |
| condition | CODA product version >= 2 | |
| path | /TOTAL_COLUMNS/NO2Tropo[] | |
| tropospheric_NO2_column_number_density_uncertainty | available | optional |
| condition | CODA product version >= 2 | |
| path | /TOTAL_COLUMNS/NO2Tropo_Error[] | |
| O3_column_number_density | available | optional |
| path | /TOTAL_COLUMNS/O3[] | |
| O3_column_number_density_uncertainty | available | optional |
| condition | CODA product version < 3 | |
| path | /TOTAL_COLUMNS/O3_Error[], /TOTAL_COLUMNS/O3[] | |
| description | derived from the relative error in percent as: O3_Error[] * 0.01 * O3[] | |
| condition | CODA product version >= 3 | |
| path | /TOTAL_COLUMNS/O3_Error[] | |
| O3_column_number_density_validity | available | optional |
| path | /DETAILED_RESULTS/QualityFlags[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘O3’ | |
| OClO_column_number_density | available | optional |
| path | /TOTAL_COLUMNS/OClO[] | |
| OClO_column_number_density_uncertainty | available | optional |
| condition | CODA product version < 3 | |
| path | /TOTAL_COLUMNS/OClO_Error[], /TOTAL_COLUMNS/OClO[] | |
| description | derived from the relative error in percent as: OClO_Error[] * 0.01 * OClO[] | |
| condition | CODA product version >= 3 | |
| path | /TOTAL_COLUMNS/OClO_Error[] | |
| OClO_column_number_density_validity | available | optional |
| path | /DETAILED_RESULTS/QualityFlags[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘OClO’ | |
| SO2_column_number_density | available | optional |
| path | /TOTAL_COLUMNS/SO2[] | |
| SO2_column_number_density_uncertainty | available | optional |
| condition | CODA product version < 3 | |
| path | /TOTAL_COLUMNS/SO2_Error[], /TOTAL_COLUMNS/SO2[] | |
| description | derived from the relative error in percent as: SO2_Error[] * 0.01 * SO2[] | |
| condition | CODA product version >= 3 | |
| path | /TOTAL_COLUMNS/SO2_Error[] | |
| SO2_column_number_density_validity | available | optional |
| path | /DETAILED_RESULTS/QualityFlags[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘SO2’ | |
| BrO_column_number_density_amf | available | optional |
| path | /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘BrO’ | |
| BrO_column_number_density_amf_uncertainty | available | optional |
| path | /DETAILED_RESULTS/AMFTotal_Error[,window], /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | derived from the relative error in percent as: AMFTotal_Error[,window] * 0.01 * AMFTotal[,window]; window is the index in MainSpecies[] that has the value ‘BrO’ | |
| H2O_column_number_density_amf | available | optional |
| path | /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘H2O’ | |
| H2O_column_number_density_amf_uncertainty | available | optional |
| path | /DETAILED_RESULTS/AMFTotal_Error[,window], /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | derived from the relative error in percent as: AMFTotal_Error[,window] * 0.01 * AMFTotal[,window]; window is the index in MainSpecies[] that has the value ‘H2O’ | |
| HCHO_column_number_density_amf | available | optional |
| path | /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘HCHO’ | |
| HCHO_column_number_density_amf_uncertainty | available | optional |
| path | /DETAILED_RESULTS/AMFTotal_Error[,window], /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | derived from the relative error in percent as: AMFTotal_Error[,window] * 0.01 * AMFTotal[,window]; window is the index in MainSpecies[] that has the value ‘HCHO’ | |
| NO2_column_number_density_amf | available | optional |
| path | /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘NO2’ | |
| NO2_column_number_density_amf_uncertainty | available | optional |
| path | /DETAILED_RESULTS/AMFTotal_Error[,window], /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | derived from the relative error in percent as: AMFTotal_Error[,window] * 0.01 * AMFTotal[,window]; window is the index in MainSpecies[] that has the value ‘NO2’ | |
| tropospheric_NO2_column_number_density_amf | available | optional |
| condition | CODA product version >= 2 | |
| path | /DETAILED_RESULTS/NO2/AMFTropo[] | |
| tropospheric_NO2_column_number_density_amf_uncertainty | available | optional |
| path | CODA product version >= 2 | |
| description | derived from the relative error in percent as: AMFTropo_Error[] * 0.01 * AMFTropo[] | |
| O3_column_number_density_amf | available | optional |
| path | /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘O3’ | |
| O3_column_number_density_amf_uncertainty | available | optional |
| path | /DETAILED_RESULTS/AMFTotal_Error[,window], /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | derived from the relative error in percent as: AMFTotal_Error[,window] * 0.01 * AMFTotal[,window]; window is the index in MainSpecies[] that has the value ‘O3’ | |
| OClO_column_number_density_amf | available | optional |
| path | /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘OClO’ | |
| OClO_column_number_density_amf_uncertainty | available | optional |
| path | /DETAILED_RESULTS/AMFTotal_Error[,window], /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | derived from the relative error in percent as: AMFTotal_Error[,window] * 0.01 * AMFTotal[,window]; window is the index in MainSpecies[] that has the value ‘OClO’ | |
| SO2_column_number_density_amf | available | optional |
| path | /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value ‘SO2’ | |
| SO2_column_number_density_amf_uncertainty | available | optional |
| path | /DETAILED_RESULTS/AMFTotal_Error[,window], /DETAILED_RESULTS/AMFTotal[,window], /META_DATA/MainSpecies[] | |
| description | derived from the relative error in percent as: AMFTotal_Error[,window] * 0.01 * AMFTotal[,window]; window is the index in MainSpecies[] that has the value ‘SO2’ | |
| O3_effective_temperature | available | optional |
| condition | detailed_results=O3 and CODA product version >= 2 | |
| path | /DETAILED_RESULTS/O3/O3Temperature | |
| pressure | available | optional |
| condition | detailed_results=HCHO and CODA product version >= 3 | |
| path | /DETAILED_RESULTS/HCHO/AveragingKernelPressureLevel | |
| description | the vertical grid is inverted to make it ascending | |
| condition | detailed_results=NO2 and CODA product version >= 3 | |
| path | /DETAILED_RESULTS/NO2/AveragingKernelPressureLevel | |
| description | the vertical grid is inverted to make it ascending | |
| HCHO_volume_mixing_ratio_dry_air_apriori | available | optional |
| condition | detailed_results=HCHO and CODA product version >= 3 | |
| path | /DETAILED_RESULTS/HCHO/AprioriHCHOProfile | |
| description | the vertical grid is inverted to make it ascending | |
| HCHO_column_number_density_avk | available | optional |
| condition | detailed_results=HCHO and CODA product version >= 3 | |
| path | /DETAILED_RESULTS/HCHO/AveragingKernel | |
| description | the vertical grid is inverted to make it ascending | |
| NO2_volume_mixing_ratio_dry_air_apriori | available | optional |
| condition | detailed_results=NO2 and CODA product version >= 3 | |
| path | /DETAILED_RESULTS/HCHO/AprioriNO2Profile | |
| description | the vertical grid is inverted to make it ascending | |
| NO2_column_number_density_avk | available | optional |
| condition | detailed_results=NO2 and CODA product version >= 3 | |
| path | /DETAILED_RESULTS/NO2/AveragingKernel | |
| description | the vertical grid is inverted to make it ascending | |
| surface_albedo | available | optional |
| condition | detailed_results set and CODA product version >= 2 | |
| path | /DETAILED_RESULTS/SurfaceAlbedo[,window], /META_DATA/MainSpecies[] | |
| description | window is the index in MainSpecies[] that has the value for which the detailed_restults opion is set | |
| cloud_fraction | condition | CODA product version < 2 |
| path | /DETAILED_RESULTS/CloudFraction[] | |
| condition | CODA product version >= 2 | |
| path | /CLOUD_PROPERTIES/CloudFraction[] | |
| cloud_fraction_uncertainty | condition | CODA product version < 2 |
| path | /DETAILED_RESULTS/CloudFraction_Error[], /DETAILED_RESULTS/CloudFraction[] | |
| description | derived from the relative error in percent as: CloudFraction_Error[] * 0.01 * CloudFraction[] | |
| condition | CODA product version >= 2 | |
| path | /CLOUD_PROPERTIES/CloudFraction_Error[], /CLOUD_PROPERTIES/CloudFraction[] | |
| description | derived from the relative error in percent as: CloudFraction_Error[] * 0.01 * CloudFraction[] | |
| cloud_top_pressure | condition | CODA product version < 2 |
| path | /DETAILED_RESULTS/CloudTopPressure[] | |
| condition | CODA product version >= 2 | |
| path | /CLOUD_PROPERTIES/CloudTopPressure[] | |
| cloud_top_pressure_uncertainty | condition | CODA product version < 2 |
| path | /DETAILED_RESULTS/CloudTopPressure_Error[], /DETAILED_RESULTS/CloudTopPressure[] | |
| description | derived from the relative error in percent as: CloudTopPressure_Error[] * 0.01 * CloudTopPressure[] | |
| condition | CODA product version >= 2 | |
| path | /CLOUD_PROPERTIES/CloudTopPressure_Error[], /CLOUD_PROPERTIES/CloudTopPressure[] | |
| description | derived from the relative error in percent as: CloudTopPressure_Error[] * 0.01 * CloudTopPressure[] | |
| cloud_top_height | condition | CODA product version < 2 |
| path | /DETAILED_RESULTS/CloudTopHeight[] | |
| condition | CODA product version >= 2 | |
| path | /CLOUD_PROPERTIES/CloudTopHeight[] | |
| cloud_top_height_uncertainty | condition | CODA product version < 2 |
| path | /DETAILED_RESULTS/CloudTopHeight_Error[], /DETAILED_RESULTS/CloudTopHeight[] | |
| description | derived from the relative error in percent as: CloudTopHeight_Error[] * 0.01 * CloudTopHeight[] | |
| condition | CODA product version >= 2 | |
| path | /CLOUD_PROPERTIES/CloudTopHeight_Error[], /CLOUD_PROPERTIES/CloudTopHeight[] | |
| description | derived from the relative error in percent as: CloudTopHeight_Error[] * 0.01 * CloudTopHeight[] | |
| cloud_top_albedo | condition | CODA product version < 2 |
| path | /DETAILED_RESULTS/CloudTopAlbedo[] | |
| condition | CODA product version >= 2 | |
| path | /CLOUD_PROPERTIES/CloudTopAlbedo[] | |
| cloud_top_albedo_uncertainty | condition | CODA product version < 2 |
| path | /DETAILED_RESULTS/CloudTopAlbedo_Error[], /DETAILED_RESULTS/CloudTopAlbedo[] | |
| description | derived from the relative error in percent as: CloudTopAlbedo_Error[] * 0.01 * CloudTopAlbedo[] | |
| condition | CODA product version >= 2 | |
| path | /CLOUD_PROPERTIES/CloudTopAlbedo_Error[], /CLOUD_PROPERTIES/CloudTopAlbedo[] | |
| description | derived from the relative error in percent as: CloudTopAlbedo_Error[] * 0.01 * CloudTopAlbedo[] | |
| cloud_optical_depth | condition | CODA product version < 2 |
| path | /DETAILED_RESULTS/CloudOpticalThickness[] | |
| condition | CODA product version >= 2 | |
| path | /CLOUD_PROPERTIES/CloudOpticalThickness[] | |
| cloud_optical_depth_uncertainty | condition | CODA product version < 2 |
| path | /DETAILED_RESULTS/CloudOpticalThickness_Error[], /DETAILED_RESULTS/CloudOpticalThickness[] | |
| description | derived from the relative error in percent as: CloudOpticalThickness_Error[] * 0.01 * CloudOpticalThickness[] | |
| condition | CODA product version >= 2 | |
| path | /CLOUD_PROPERTIES/CloudOpticalThickness_Error[], /CLOUD_PROPERTIES/CloudOpticalThickness[] | |
| description | derived from the relative error in percent as: CloudOpticalThickness_Error[] * 0.01 * CloudOpticalThickness[] | |
| absorbing_aerosol_index | path | /DETAILED_RESULTS/AAI[] |
| surface_heigth | path | /DETAILED_RESULTS/SurfaceHeight[] |
| surface_pressure | path | /DETAILED_RESULTS/SurfacePressure[] |
| scan_subindex | path | /GEOLOCATION/SubPixelInScan[] |
| description | the pixel id is actually the pixel id relative to the L1b MDR, which is off by one with regard to the scan; the MDR pixel id is therefore converted to a real scan pixel id by subtracting one and performing a modulo 32 | |
| scan_direction_type | path | /GEOLOCATION/IndexInScan[] |
| description | the scan direction is based on IndexInScan[]; 0-2: forward (0), 3: backward (1) |


coronavirus research novel Accessed control COVID- January articles prevention Health China studies {border-style Feb patients published reported China. Chinese cases infection px;} #ffffff;} (), outbreak Wuhan, pneumonia respiratory transmission clinical early health Commission National spread study Republic treatment People’s Wuhan causes, included measures review symptoms use care following infected manifestation medical population public Wang people Clinical International Med Zhang data new publications px; virus {font-family COVID-. English Jan Prevention Zhou confirmed diagnosis, epidemic font-size information provide scoping (as ./.... China, December Fig. Hubei Novel Research Seafood WHO. age article contact coronaviruses diagnosis domains double; epidemiology, file findings human include indicated methodological n = , potential risk scientific suggested (with -nCoV .%) Center Chin Commons Creative Huanan Market Medical Province, Public Studies Table Yang [], associated based border-color border-width cause characteristics community, conduct exposure general guidelines history identified including literature market masks psychological range ranging related relevant researchers samples search sequence solid; ways {font-style {font-weight (.%) (Table Average CDC COVID-, Causes Chen China: Coronavirus Disease Epidemiology January, Lancet. Med. Notice PRISMA SARS SARS-CoV- Study Total World analysis analyzed appropriate bioRxiv. bold caused collection common conducted considered control. countries courier; death different disease distribution droplets em; epidemiological epidemiology fever, guideline hand identity) includes issued language majority national nosocomial number n = ) outside papers prevent pt;} publication rapid regarding response sample source specific strategies suspected syndrome transmission. used days years years,


Piper Longbow:
I have found the
saint
that you were looking for! She is in a
tent near the Altar of Rites
!


Let me start out by saying that Seroquel - an anti-schizophrenia drug - is NOT fun and is NOT recreational.. so just leave it alone.
I haven't done a large variety of drugs in the past. I've done alcohol a lot; smoked boatloads of reefer; tried salvia a few times with minimal success; popped hydrocodone, codeine, and tramadol various times. That's about it.
3 days ago a friend of mine came over to sell me 1/8th oz of pot and mentioned that he had some pills - the Seroquel 200s - that he called a really fun tranquilizer. Another friend I was with at the time said he tried them (at a much lower dosage, which I didn't know at the time) and they were great fun. Usually I research any new drug before I try it, but this time I figured it would be OK because I trust these people.. and that IS A BIG MISTAKE. Even if they are your good friends and wouldn't lie to you, you need to research the drug on your own to see how it could affect you. Those friends might not know what will happen.
Anyways, I popped one Seroquel 200 and smoked about a 15 sack worth of MJ between me and the three others present. The usual marijuana buzz hit quick, being as I smoked out of a bong this time, and it was very pleasant. About 30-45 minutes into it, I started to feel real sluggish and laughed hysterically. Sometimes I'd laugh so hard at nothing, I'd collpase onto the floor and struggle for air through the laughing. At this time I thought 'Hey, this isn't so bad, I should do it more often' and traded a joint for 3 more of these demon pills. Thank God almighty that I didn't take them then, as a matter of fact I still have them and have no intention of taking them, because something really bad could have happened.
About an hour and a half after I had the pill, I felt really tired. But, when I went to lay down, my legs would get restless. So, to try to alleviate the restlessness, I'd get up and walk around. Walking (or even standing or sitting for that matter) caused extreme blood rushes to my head and very fast heart beating and were very VERY uncomfortable. This feeling of restlessness and hypertension persisted for about 8-10 hours. As an attempt to sober up, I took a shower. The shower felt relaxing, but once I got out I was SEVERELY lightheaded. I had to rush into my room and lay in bed to avoid passing out. My vision started to cloud up so I could see just a little bit in the center and the rest was pitch black. I had to lay down for about 20 minutes before this feeling went away. I lied on the couch for the remainder of the day, in and out of sleep, until I went to my bed that night and slept till the morning.
The next day, the major problems were gone, but I still felt a little disoriented and detached all day. Today, 3 days later, I still feel slightly detached, but overall I'm back to normal.
 I learned my lesson the hard way, but at least I learned it.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.