One aspect of the proposal is to construct \"active\" database software
spanning the scales of chemistry and DNS that have both the ability to
interact on demand with multi-scale simulations and the ability to
interact with the provider of database information. Such capability
pivots around intelligent databases, strategically placed at different
scale levels. The databases are able to exchange information as needed.
When the user queries a database at some particular scale level, the
database should be able to contact databases at other levels as needed.

Here is a concocted use case scenario that sticks to the chemistry
scale, primarily out of ignorance on our part of the finer details on
other scales.

The scenario (intentionally) does not specify where the various tables
are located, where exactly is the data stored, where exactly does data
processing occur, how is security handled, which protocols are being
used during the information exchanges, etc. Rather, it
phenomenologically describes what actions are happening during the
scenario, mostly from the user viewpoint with a few background details.

For this case let us suppose that there are, among others, four tables
in place:

-   An active thermochemical table that includes a large number of
    gas-phase species important in combustion and atmospheric chemistry
    as well as others. In particular, all species present in the GRI
    Mech are included.

-   An active kinetic rate table that includes all known reactions
    relevant to combustion and atmospheric chemistry, as well as a
    significant number of others. In particular, all known reactions
    relevant to natural gas combustion are included.

-   A separate table of experimental information that GRI Mech has used
    in the past, as well as other similar data.

-   A table of several combustion-related mechanisms. One of these is
    the GRI Mech.

All of the above tables are able to provide specific information on
demand and respond both to manual queries from the user and automated
queries by other tables and simulation applications. The range of
information is very large, starting from, for example, delivering a
specific property calculated at a specific temperature, to more involved
details such as which exact method is used to calculate the needed
information or a detailed pedigree of the data used internally. In
addition, the two active tables are able to query each other as well as
a number of other static tables available electronically. They are also
able to interact with the user or her simulation applications in the
sense that they can accept new data on a provisional basis, check that
data for consistency against the internal data as well as data available
from other tables, both static and active, analyze the consequences that
would occur if the new is accepted and feed back an evaluation report.
Let us suppose that both active tables have also the ability to
empirically estimate missing information (via additivity schemes etc).
Let us finally suppose that both active tables have the ability to
launch a calculation for missing information.

Let us suppose that the user has some extensive experimental
measurements performed on a complex real environment (such as a flame)
regarding a large number of species, and that she is trying to simulate
the measured concentration profiles using GRI Mech. Let us also suppose
that, while the initial simulation is not too bad for some of the
species, it grossly misses to reproduce several species and is slightly
off the mark for some other species.

By looking at the outcome of the initial simulation, the user decides
that most likely in her particular case a few reactions not present in
the GRI Mech may be important. She accesses the CMCS portal and from it
(or through it) the table listing various mechanisms. After some poking
around, she dreams up her own mechanism with 20 reactions that she hopes
may be sufficient to explain her data. Let\'s suppose that 16 of those
rates are from GRI Mech and 4 are not represented in GRI Mech.

At this point the two active rate and thermo tables are waiting to be
queried. They are in their \"official\" or "anointed" latest edition
state. This implies that that all rates and all thermochemistry
contained within those two active tables is completely consistent both
internally and across the two tables. (This state was achieved during
the last "official" update that has occurred, at which point the
previous "official" state was pushed to the archives.)

Using the portal, the user queries the active rate table to get the rate
expressions which she will use in her model. Out of the 4 new rates not
in GRI Mech, the rate table finds in the core database 2 rates and their
error bars, but has problems with the remaining 2 rates. One rate (X) is
totally unknown; the other (Y) has only the reverse rate in the table.

At this point the rate table queries the thermo table for the
thermochemistry of species involved in X and Y to be able to estimate
rate X and find the forward rate Y.

Let us suppose that the thermo table can satisfy the demand of the rate
table for all species except for species y1 and y2, on which very little
is known.

In order to fully satisfy the query from the rate table, the thermo
table estimates by group additivity the thermochemistry of y1 and y2 as
a first shot, but also proposes to launch two G3 (on NWChem)
calculations as a better alternative (after checking out the G3 archive
and verifying that those species have not yet been calculated) and
notifies the rate table, which in turn notifies the user. Species y1 is
stable, and the user decides she can accept the estimate. Species y2 is
a radical, and the user opts for a calculation. The thermo table sends
the needed information to NWChem to launch a calculation. When the
calculated value for y2 becomes available, the thermo table prepares for
the user a private \"what if\" copy of itself, introduces the
estimated/calculated values for y1 and y2, checks for consistency with
the rest of its core database and adjusts the error bars accordingly.
During this adjustment process, values for several other species and
most error bars across the table change a little. The table feeds the
info for y1 and y2, as well as the info with tweaked values and error
bars for all other species to the rate table.

The rate table now copies itself into a private edition and first checks
how the new tweak affects the existing rates. Then it uses the supplied
thermochemistry to figure the forward rate Y. For rate X it uses an
empirical scheme (based on additivity/similarity principles). The table
notifies the user of what has been done for these two rates, proposing
calculations as alternatives. The user accepts Y but requests a
calculation for X. The table launches a magic program
\"Quick_and_accurate_rates\" (no such general code exists but fragments
of this exist and other parts are under SciDAC BES development), which
in turn asks the user to select the effort she wants to invest in this
by selecting the level of theory applied to get the rate and its range
of uncertainty. Since she happens to be not particularly proficient in
this kind of theory, she selects the proposed default level of
calculation. The code executes and shuttles the result to the rate
table. Once the rate table gets the result, it updates the user's
private edition with rates X and Y, checks them for consistency against
the core database, adjusts the error bars for these rates and provides
all 20 rates to the user.

After doing simulations using her new 20 reaction mechanism, the user
concludes that she may be able to better fit the data either by
increasing rate Y by a factor of two or decreasing rate X by a factor of
two. She goes back to her stored private edition of the rate table and
tries the new, larger rate Y. The table checks this for consistency with
the core data and finds that this would requires a change of enthalpy of
species y1. The rate table now queries the thermo table, which
determines that this would be seriously inconsistent with other
thermochemical quantities in the core database. The user is notified.
Rather than forcing rate Y (which is also an offered option) and
affecting all other thermochemistry and rates in the process, she now
tries to change rate X. This is (for example) found consistent with the
remainder of the rates in the core database, but it requires a change in
the thermochemistry of x1. The rate table queries the thermo table,
which finds that the proposed thermochemistry of x1 is consistent with
the core data within a certain error bar.

After trying the simulations with the new set of rates, the user finds
that while the simulation is getting better, there is still room for
improvements. Hence, she uses the portal to launch a new run of
\"Quick_and_accurate_rates\" requesting a higher level of effort and an
improved level of accuracy.

For the sake of this example, let us suppose that in the end she
concludes that

a)  One of the measured species (something she slightly suspected from
    the beginning) needs to be remeasured more carefully, and

b)  The simulation using new rates is congruent with all the other
    measured profiles.

As a consequence, the 16 rates in GRI Mech need to be tweaked a little
and the mechanism expanded to be applicable to cases similar to hers.
She includes her data (corrected using the new measurements for the
problem species) along with the data in the coupled kinetics table and
her expanded mechanism and tries a new optimization of all the
experiments to re-tweak the GRI Mech. On this basis she may decide her
experiments are slightly off and need all to be redone more carefully,
or that GRI Mech can be tweaked a little to get better agreement with
her experiment or that her search for a proper mechanism applicable to
her situation has to go through another loop, maybe involving yet
another 2 reactions, or...

Let us suppose that after she has performed several loops of
improvements, she starts realizing that her experimental results are not
quite consistent with the available knowledge of thermochemistry, rates,
and mechanisms. She goes back to the lab, makes improvements of her
experimental setup, remeasures all species and starts all over at the
top of this scenario.

Let us suppose that in the second iteration of this case she finally
finds good agreement with her data. At this point she has a set of rates
and a mechanism that explains her data well, including two new (now
experimentally verified) rates and a new thermochemistry for x1. She
submits these new experimental values to the active table keepers for
consideration to be included in the "official" edition. The process
allows as an option the possibility of storing in the interim her
data/mechanism/rates/thermochemistry in a "tentative" database together
with "hot" data from other users, available publicly to those who may
wish to go beyond the "official" data.

Obviously, even within the chemistry scale many more scenarios could be
concocted exploring and focusing on other envisioned features of the
tables, their modes of interaction, the various features available on
the portal, etc.

Also, it is obvious that other examples that start at a different scale
and percolate down to the chemistry scale can be concocted as well.
However, the basic philosophy of interaction between databases at
adjacent scales would be analogous to what is described here.

One point to be made is that with active tables placed at various levels
of scale it is possible not only to have simulations seamlessly use data
from various scales, but data producers can see the consistency (or lack
thereof) of their data with what is already known. In a sense, data
providers get access to a much large range of information to test the
nominal value and error bars of either their experiments or
calculations. This accelerates the accuracy of the input data to
simulations and hence the accuracy of the simulations**.**