Using importlib_metadata
¶
importlib_metadata
is a library that provides for access to installed
package metadata. Built in part on Python’s import system, this library
intends to replace similar functionality in the entry point
API and metadata API of pkg_resources
. Along with
importlib.resources
in Python 3.7
and newer (backported as importlib_resources for older versions of
Python), this can eliminate the need to use the older and less efficient
pkg_resources
package.
By “installed package” we generally mean a third-party package installed into
Python’s site-packages
directory via tools such as pip. Specifically,
it means a package with either a discoverable dist-info
or egg-info
directory, and metadata defined by PEP 566 or its older specifications.
By default, package metadata can live on the file system or in zip archives on
sys.path
. Through an extension mechanism, the metadata can live almost
anywhere.
Overview¶
Let’s say you wanted to get the version string for a package you’ve installed
using pip
. We start by creating a virtual environment and installing
something into it:
$ python3 -m venv example
$ source example/bin/activate
(example) $ pip install importlib_metadata
(example) $ pip install wheel
You can get the version string for wheel
by running the following:
(example) $ python
>>> from importlib_metadata import version
>>> version('wheel')
'0.32.3'
You can also get the set of entry points keyed by group, such as
console_scripts
, distutils.commands
and others. Each group contains a
sequence of EntryPoint objects.
You can get the metadata for a distribution:
>>> list(metadata('wheel'))
['Metadata-Version', 'Name', 'Version', 'Summary', 'Home-page', 'Author', 'Author-email', 'Maintainer', 'Maintainer-email', 'License', 'Project-URL', 'Project-URL', 'Project-URL', 'Keywords', 'Platform', 'Classifier', 'Classifier', 'Classifier', 'Classifier', 'Classifier', 'Classifier', 'Classifier', 'Classifier', 'Classifier', 'Classifier', 'Classifier', 'Classifier', 'Requires-Python', 'Provides-Extra', 'Requires-Dist', 'Requires-Dist']
You can also get a distribution’s version number, list its constituent files, and get a list of the distribution’s Distribution requirements.
Functional API¶
This package provides the following functionality via its public API.
Entry points¶
The entry_points()
function returns a dictionary of all entry points,
keyed by group. Entry points are represented by EntryPoint
instances;
each EntryPoint
has a .name
, .group
, and .value
attributes and
a .load()
method to resolve the value. There are also .module
,
.attr
, and .extras
attributes for getting the components of the
.value
attribute:
>>> eps = entry_points()
>>> list(eps)
['console_scripts', 'distutils.commands', 'distutils.setup_keywords', 'egg_info.writers', 'setuptools.installation']
>>> scripts = eps['console_scripts']
>>> wheel = [ep for ep in scripts if ep.name == 'wheel'][0]
>>> wheel
EntryPoint(name='wheel', value='wheel.cli:main', group='console_scripts')
>>> wheel.module
'wheel.cli'
>>> wheel.attr
'main'
>>> wheel.extras
[]
>>> main = wheel.load()
>>> main
<function main at 0x103528488>
The group
and name
are arbitrary values defined by the package author
and usually a client will wish to resolve all entry points for a particular
group. Read the setuptools docs
for more information on entry points, their definition, and usage.
Distribution metadata¶
Every distribution includes some metadata, which you can extract using the
metadata()
function:
>>> wheel_metadata = metadata('wheel')
The keys of the returned data structure 1 name the metadata keywords, and their values are returned unparsed from the distribution metadata:
>>> wheel_metadata['Requires-Python']
'>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*'
Distribution versions¶
The version()
function is the quickest way to get a distribution’s version
number, as a string:
>>> version('wheel')
'0.32.3'
Distribution files¶
You can also get the full set of files contained within a distribution. The
files()
function takes a distribution package name and returns all of the
files installed by this distribution. Each file object returned is a
PackagePath
, a pathlib.Path
derived object with additional dist
,
size
, and hash
properties as indicated by the metadata. For example:
>>> util = [p for p in files('wheel') if 'util.py' in str(p)][0]
>>> util
PackagePath('wheel/util.py')
>>> util.size
859
>>> util.dist
<importlib_metadata._hooks.PathDistribution object at 0x101e0cef0>
>>> util.hash
<FileHash mode: sha256 value: bYkw5oMccfazVCoYQwKkkemoVyMAFoR34mmKBx8R1NI>
Once you have the file, you can also read its contents:
>>> print(util.read_text())
import base64
import sys
...
def as_bytes(s):
if isinstance(s, text_type):
return s.encode('utf-8')
return s
In the case where the metadata file listing files
(RECORD or SOURCES.txt) is missing, files()
will
return None
. The caller may wish to wrap calls to
files()
in always_iterable
or otherwise guard against this condition if the target
distribution is not known to have the metadata present.
Distribution requirements¶
To get the full set of requirements for a distribution, use the requires()
function:
>>> requires('wheel')
["pytest (>=3.0.0) ; extra == 'test'", "pytest-cov ; extra == 'test'"]
Distributions¶
While the above API is the most common and convenient usage, you can get all
of that information from the Distribution
class. A Distribution
is an
abstract object that represents the metadata for a Python package. You can
get the Distribution
instance:
>>> from importlib_metadata import distribution
>>> dist = distribution('wheel')
Thus, an alternative way to get the version number is through the
Distribution
instance:
>>> dist.version
'0.32.3'
There are all kinds of additional metadata available on the Distribution
instance:
>>> d.metadata['Requires-Python']
'>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*'
>>> d.metadata['License']
'MIT'
The full set of available metadata is not described here. See PEP 566 for additional details.
Extending the search algorithm¶
Because package metadata is not available through sys.path
searches, or
package loaders directly, the metadata for a package is found through import
system finders. To find a distribution package’s metadata,
importlib.metadata
queries the list of meta path finders on
sys.meta_path
.
By default importlib_metadata
installs a finder for distribution packages
found on the file system. This finder doesn’t actually find any packages,
but it can find the packages’ metadata.
The abstract class importlib.abc.MetaPathFinder
defines the
interface expected of finders by Python’s import system.
importlib_metadata
extends this protocol by looking for an optional
find_distributions
callable on the finders from
sys.meta_path
and presents this extended interface as the
DistributionFinder
abstract base class, which defines this abstract
method:
@abc.abstractmethod
def find_distributions(context=DistributionFinder.Context()):
"""Return an iterable of all Distribution instances capable of
loading the metadata for packages for the indicated ``context``.
"""
The DistributionFinder.Context
object provides .path
and .name
properties indicating the path to search and name to match and may
supply other relevant context.
What this means in practice is that to support finding distribution package
metadata in locations other than the file system, subclass
Distribution
and implement the abstract methods. Then from
a custom finder, return instances of this derived Distribution
in the
find_distributions()
method.
Footnotes
- 1
Technically, the returned distribution metadata object is an
email.message.EmailMessage
instance, but this is an implementation detail, and not part of the stable API. You should only use dictionary-like methods and syntax to access the metadata contents.


After listening to today’s episode of Connected, I want to throw out my guesses for what Apple’s laptop line will look like if this new rumored 13” MacBook Air comes out.
MacBook
After hearing the rumors, I think the 12” MacBook will stick around and the new laptop will be called the 13” MacBook. While this is closer in screen size than the 11 and 13” MacBook Airs were, I think the differentiator will be the thickness and power. If Apple is going to use the chip class of the Air and MacBook Escape, they can’t possibly do that in the thin body of the current MacBook. But I think they need to keep the current sized MacBook around for people whose primary need is something small and light.
MacBook Pro
Speaking of the MacBook Escape, I think this is the computer that goes away. This leaves the Pro line of MacBooks with only the 13” and 15” models with Touchbar. It seems like the Escape was Apple’s attempt to replace the Air, and it hasn’t succeeded. If this new 13” model fills that space, why would the Escape need to exist?
This is all of course conjecture. I really just want to be able to say I was right on the off chance I turn out to be come June.


Object
`Trail` is the public container class for holding paths and extensions.
`Index#aliases` is a mutable `Hash` mapping an extension to an `Array` of aliases.
trail = Hike::Trail.new trail.paths.push "~/Projects/hike/site" trail.aliases['.htm'] = 'html' trail.aliases['.xhtml'] = 'html' trail.aliases['.php'] = 'html'
Aliases provide a fallback when the primary extension is not matched. In the example above, a lookup for “foo.html” will check for the existence of “foo.htm”, “foo.xhtml”, or “foo.php”.
`Trail#extensions` is a mutable `Extensions` collection.
trail = Hike::Trail.new trail.paths.push "~/Projects/hike/lib" trail.extensions.push ".rb"
Extensions allow you to find files by just their name omitting their extension. Is similar to Ruby's require mechanism that allows you to require files with specifiying `foo.rb`.
`Trail#paths` is a mutable `Paths` collection.
trail = Hike::Trail.new trail.paths.push "~/Projects/hike/lib", "~/Projects/hike/test"
The order of the paths is significant. Paths in the beginning of the collection will be checked first. In the example above, `~/Projects/hike/lib/hike.rb` would shadow the existent of `~/Projects/hike/test/hike.rb`.
A Trail accepts an optional root path that defaults to your current working directory. Any relative paths added to `Trail#paths` will expanded relative to the root.
# File lib/hike/trail.rb, line 48 def initialize(root = ".") @root = Pathname.new(root).expand_path @paths = Paths.new(@root) @extensions = Extensions.new @aliases = Hash.new { |h, k| h[k] = Extensions.new } end
Alias `new_extension` to `old_extension`
# File lib/hike/trail.rb, line 95 def alias_extension(new_extension, old_extension) aliases[normalize_extension(new_extension)] = normalize_extension(old_extension) end
Append `extension` to `Extensions` collection
# File lib/hike/trail.rb, line 84 def append_extensions(*extensions) self.extensions.push(*extensions) end
Append `path` to `Paths` collection
# File lib/hike/trail.rb, line 67 def append_paths(*paths) self.paths.push(*paths) end
`Trail#entries` is equivalent to `Dir#entries`. It is not recommend to use this method for general purposes. It exists for parity with `Index#entries`.
# File lib/hike/trail.rb, line 159 def entries(*args) index.entries(*args) end
`Trail#find` returns a the expand path for a logical path in the path collection.
trail = Hike::Trail.new "~/Projects/hike" trail.extensions.push ".rb" trail.paths.push "lib", "test" trail.find "hike/trail" # => "~/Projects/hike/lib/hike/trail.rb" trail.find "test_trail" # => "~/Projects/hike/test/test_trail.rb"
`find` accepts multiple fallback logical paths that returns the first match.
trail.find "hike", "hike/index"
is equivalent to
trail.find("hike") || trail.find("hike/index")
Though `find` always returns the first match, it is possible to iterate over all shadowed matches and fallbacks by supplying a block.
trail.find("hike", "hike/index") { |path| warn path }
This allows you to filter your matches by any condition.
trail.find("application") do |path| return path if mime_type_for(path) == "text/css" end
# File lib/hike/trail.rb, line 138 def find(*args, &block) index.find(*args, &block) end
`Trail#index` returns an `Index` object that has the same interface as `Trail`. An `Index` is a cached `Trail` object that does not update when the file system changes. If you are confident that you are not making changes the paths you are searching, `index` will avoid excess system calls.
index = trail.index index.find "hike/trail" index.find "test_trail"
# File lib/hike/trail.rb, line 152 def index Index.new(root, paths, extensions, aliases) end
Prepend `extension` to `Extensions` collection
# File lib/hike/trail.rb, line 78 def prepend_extensions(*extensions) self.extensions.unshift(*extensions) end
Prepend `path` to `Paths` collection
# File lib/hike/trail.rb, line 61 def prepend_paths(*paths) self.paths.unshift(*paths) end
Remove `extension` from `Extensions` collection
# File lib/hike/trail.rb, line 90 def remove_extension(extension) self.extensions.delete(extension) end
Remove `path` from `Paths` collection
# File lib/hike/trail.rb, line 73 def remove_path(path) self.paths.delete(path) end
`Trail#root` returns root path as a `String`. This attribute is immutable.
# File lib/hike/trail.rb, line 56 def root @root.to_s end
`Trail#stat` is equivalent to `File#stat`. It is not recommend to use this method for general purposes. It exists for parity with `Index#stat`.
# File lib/hike/trail.rb, line 166 def stat(*args) index.stat(*args) end
Generated with the Darkfish Rdoc Generator 2.


ApnaOPD
Home
Patient
Doctor
Retailer
Order Detail
[[name]]
Accept
Decline
Fill Quotation Details :
-
+
Total Offer Price :
0.0
Delivery Charge :
Delivery Time :
Total Charge :
0.0
Send


This site has been deployed using GitHub, Jenkins and VMware Cloud PKS (formerly known as VKE).
The code is available on github.com/dmurana/devopsday_cicd_demo
At AT Innovando Juntos we work with cloud computing, network virtualization, business continuity, DevOps, end-user computing and other interesting and innovative stuff.
If you are interested in some of these topics, do not hesitate to ask us!
This is a simple demo website created to demonstrate how Kubernetes and CI/CD works.
It has been based on the free HTML5 template called "Windows", published on HTML5-Templates.com


My final project idea was really cool and it super worked. The genreal idea was that I wanted to make my own lamp with led lights. The first stage was to cut up some bright color piping. The second stage was create a flat base. I used a square peice of wood, and round the corners so that it looked nicer. Then I had to create holes in the wood that were the right size as the piping. The right size as in big enough to fit and small enough to make sure the poles wouldn't slip out. The third stage was to appeal to the aesthic side of the project. I did multple layers of spray spaint so that each would show through and create a really nice color. The fourth stage was to raster some words or designs on my pipes. I went with the names of my two brothers, 'Javier' and "Elisha', and I also engraved the word family. The fifth stage which was the hardest was to saudert the LED lights for my lamp. On the LED strip of lights I had to smake sure i saudert the correct parts so that I could get the correct color, which is blue. After sauderting my LED lights I had to go back to my wood base and create channels on the bottom connecting the holes so that the wiring would go through and the base could lay flat. And then finally I wrapped a peice of cloth around the top to give it a nice hippie vibe.


Developer Bar
Initializing...
Calibrate the corners of your screen clockwise from top-left. Then press spacebar to start!
+
+
+
+


This is a modified version of ostrstream for Eco Lab use, with slightly altered behaviour making it more suited for Eco Lab use.
In particular, operator<<
add spaces in between its arguments,
and a new operator|
is defined that is similar to ostrstream
operator<<
. This makes it easier to construct TCL commands.
Note that |
has higher precedence than <<
, so when
mixing the two, ensure that no <<
operator appears to the right
of |
, or use brackets to ensure the correct interpretaion:
eg.
s << a << b | c;or
(s | a) << b | c;but not
s | a << b | c;
In any case, you'll most likely get a compiler warning if you do the wrong thing.
eco_strstream is derived from eco_string class, so has
all the string behaviour. The str()
member is defiend as
equivalent to a (char*)
cast for compatibility with ostrstream.
However, the contents of the char*
are not frozen, unless
explicitly specified with freeze() (opposite to ostrstream behaviour).
class eco_strstream: public eco_string { public: char* str() const; template<class T> eco_strstream& operator<<(const T x); template<class T> eco_strstream& operator|(T); } inline ostream& operator<<(ostream& x, eco_strstream& y);


Here we are specifying the default email address for the server administrator:
# set the server administrator email
SetEnv SERVER_ADMIN<EMAIL_ADDRESS>Note: only specify your email address if you are okay with getting lots of spam ;)


Qpyl package¶
Qpyl is a Python library for efficient setup, parametrization, calibration, and analysis of EVB simulations in software package Q.
The core functionality related to Q input/ouput handling, parameter conversion and Q executable wrappers are implemented in the subpackage Qpyl.core.
Modules on this level implement high-level functionality for analysis of simulations (qanalysis), generating simulation inputs (geninp), calculating and calibration free energy profiles (qmapper), calculating LRA group contributions (qgroupcontrib) and generating FEP files (qmakefep).
Subpackages¶
Submodules¶
Qpyl.common module¶
This module contains some common classes and functions, including simple statistical methods and data structures.
-
class
Qpyl.common.
DataContainer
(coltitles)[source]¶ Bases:
object
Contains a two dimensional array of values:
- [ [ row1_column1, row1_column2, row1_column3, ...],
- [ row2_column1, row2_column2, row2_column3, ...], ... ]
and column titles.
Parameters: coltitles (list) – column titles Examples
>>> dg_de = DataContainer( ['Energy_gap', 'dG'] ) >>> dg_de.add_row( [-300.0, 10.0 ] # reversed rows >>> rows = dg_de.get_rows( reversed(dg_de.column_titles) ) >>> cols = dg_de.get_columns( columns=[0, 1] )
-
add_row
(row)[source]¶ Add a row.
Parameters: row (list) – a list of values Raises: ValueError
– if number of elements in row is not equal to number of column titles
-
class
Qpyl.common.
SpecialFormatter
(fmt=None, datefmt=None)[source]¶ Bases:
logging.Formatter
-
FORMATS
= {'DEFAULT': '%(message)s', 10: 'DBG: %(module)s: %(lineno)d: %(message)s', 20: '# %(message)s', 50: '\nCRITICAL: %(message)s\n', 30: '\nWARNING: %(message)s\n'}¶
-
-
Qpyl.common.
backup_file
(filename)[source]¶ Check if a file exists, make a backup (#filename.1#, #filename.2#...).
Parameters: filename (string) – name of file to backup Returns: - basename of the new filename or empty
- string if the file was not found.
Return type: backup_filename (string)
-
class
Qpyl.common.
gzopen
(fname)[source]¶ Bases:
object
Generic opener that decompresses gzipped files if needed. Encapsulates an open file or a GzipFile. Use the same way you would use ‘open()’.
-
Qpyl.common.
init_logger
(name, level=None, handler=None, formatter=None)[source]¶ Helper function for initializing the logger.
Parameters: - name (string) – module name, usually root: ‘Qpyl’
- level (int, optional) – logging level (DEBUG, INFO, WARNING...), default is INFO
- handler – (logging.Handler, optional): default is StreamHandler(sys.stdout) formatter: (logging.Formatter, optional): default is SpecialFormatter
Returns: lg (logging.Logger)
-
class
Qpyl.common.
np
[source]¶ -
static
kendall_tau
(list_a, list_b)[source]¶ Calculate Kendall’s tau-a correlation coefficient.
Parameters: - list_a (list) – list of ints/floats
- list_b (list) – list of ints/floats
-
static
-
Qpyl.common.
raise_or_log
(message, exception_class, logger, ignore_errors)[source]¶ Method used for raising exceptions or writting them to logger instead
This way one can bypass certain exceptions like non-integer charge groups, that may occur in weird scenarios (Amber bonding metal model).
Critical level is always used for logging.
Qpyl.plotdata module¶
This module contains the class for custom data structure PlotData used for storing various analysis data. It also contains custom JSON encoder and decoder classes which allow saving the objects in JSON format.
-
class
Qpyl.plotdata.
PlotData
(title, plot_type='line', xlabel=None, ylabel=None, zlabel=None)[source]¶ Bases:
object
Qpyl.qanalysis module¶
Module for analysing Qfep and Qdyn output (logfiles). Two main classes are QAnalyseFeps and QAnalyseDyns. See q_analysefeps.py and q_analysedyns.py for usage.
-
class
Qpyl.qanalysis.
QAnalyseDyns
(qdyn_outputs, time_unit='ps', step_size=None)[source]¶ Bases:
object
Wrapper class for QanalyseDyn for parsing a sequence of Qdyn outputs.
Parameters: - qdyn_outputs (list) – Qdyn output pathnames
- time_unit (string) – fs,ps,ns (optional, default is ps)
- step_size (float) – use in case the output reads 0.000
Examples
>>> qads = QAnalyseDyns(["fep_000.log", "fep_001.log"], timeunit="ps") # get average temperatures by combining all outputs >>> print qads.get_temp_stats()
Raises QAnalyseDynsError (if it fails to parse an output)
-
get_energies
(e_type, stride=1)[source]¶ Get energies from all logfiles combined.
Parameters: - e_type (string) – keys in QDynOutput.map_en_section dictionary
- stride (int, optional) – use only every Nth point, default=1
Returns: energies (DataContainer)
-
get_offdiags
(stride=1)[source]¶ Get distances from all logfiles combined.
Parameters: stride (int, optional) – use only every Nth point, default=1 Returns: - e.g: { “13_31”: DataContainer,
- “13_18”: DataContainer }
Return type: distances (dict)
-
get_plotdata
(stride=1)[source]¶ Return ‘useful data’ as a dictionary of PlotData objects.
Useful data: - Temperatures - Offdiagonal distances - Energies (Q and non-Q)
Parameters: stride (int, optional) – use only every Nth point, default=1
-
get_q_energies
(qe_type, evb_state, stride=1)[source]¶ Get Q energies from all logfiles combined.
Parameters: - qe_type (string) – keys in QDynOutput.map_qen_section dictionary
- evb_state (int) – 1 or 2 or 3...
- stride (int, optional) – use only every Nth point, default=1
Returns: energies (DataContainer)
-
class
Qpyl.qanalysis.
QAnalyseFeps
(qfep_outputs, lra_lambdas=None, _parent=None, _subcalc_key=None)[source]¶ Bases:
object
Wrapper class for QFepOutput for analysing multiple outputs.
Calculates statistics (mean, stdev,...), makes pretty summaries, extracts all data to PlotData objects via neat functions.
Parameters: - qfep_outputs (list of strings or list of tuples(string, string)) – pathnames of qfep outputs or (name, output_string) tuples
- lra_lambdas (list of floats, optional) – lambdas at which LRA energies should be calculated at. Usual case is (1.0, 0.0). Default = None (no LRA calcs)
- _parent (QAnalyseFeps) – used internally for QCP and exclusions
- _subcalcs (string) – used internally for QCP and exclusions
Examples
>>> qos = [os.path.join(md, "qfep.log") for md in sorted(mapdirs)] >>> qaf = QAnalyseFeps(qos, lra_lambdas=(1.0, 0.0)) >>> print qaf.stats_str # prints statistics >>> for sub_calc_key, sub_calc in sorted(qaf.sub_calcs.iteritems()): >>> print sub_calc.stats_str # prints subcalculation (QCP, GE) statistics >>> for failed_path, failed_msg in sorted(qaf.failed.iteritems()): >>> relp = os.path.relpath(failed_path) >>> print "-> {}: {}".format(relp, failed_msg) # prints failed
-
dg_all
¶ DataContainer with all main and subcalc free energies.
-
lra_stats
¶ Calculate average and st.dev of LRA and reorg energies.
-
plotdata
¶ Return ‘useful data’ as a dictionary of PlotData objects.
Each qfep_output will be a subplot in one PlotData, except in the case of LRA where there is only one subplot: the average and stdev over all outputs.
Useful data: - All energies from part 0 - FEP back, forward and average dG profiles vs lambda - FEP delta (forward - reverse) vs lambda - Binning overlap/histograms - Full dGg profile (not bin-averaged) for first output - LRA contributions (statistics) - Free energy profiles vs Egap (bin-averaged)
-
stats_str
¶ Free energy stats in string format.
Qpyl.qgeninp module¶
This module contains functions for generating FEP and equilibration inputs for Qdyn. Example of procedure files can be found in qtools/template_examples/
-
Qpyl.qgeninp.
genfeps
(fep_proc_file, relax_input_file, restraint, energy_list_fn, frames, repeats, fromlambda, prefix, first_frame_eq, pdb_file=None, fep_file=None, runscript_file=None, ignore_errors=False)[source]¶ Generates inputs for a FEP/MD simulation with Q (Qdyn).
Parameters: - fep_proc_file (string) – genfeps procedure file pathname
- relax_input_file (string) – pathname of last relaxation step input
- restraint (string) – restraint coordinate (a)
- energy_list_fn (string) – name of file that will contain the en.f.list
- frames (int) – number of FEP frames
- repeats (int) – number of repeats/replicas
- fromlambda (float) – starting lambda (0.0 - 1.0)
- prefix (string) – prefix for repeat directories
- first_frame_eq (boolean) – use equil instead of first frame (cadee)
- Optional args:
- pdb_file (string): pdb pathname (used to convert placeholders) fep_file (string): alternate fep file pathname (ignoring input’s fep) runscript_file (string): slurm/sge run script ignore_errors (boolean): passed to QStruct and QDynInp - write to logger instead of raising exceptions on non-critical things
Returns: list of created replica folders Return type: rep_dirs (list) (a) Restraint coordinate can be set to: ‘inp’ - whatever is defined in relax_input_file ‘top’ - topology ‘relax’ - endpoint of relaxation
-
Qpyl.qgeninp.
genrelax
(relax_proc_file, outdir, restraint, top_file=None, fep_file=None, runscript_file=None, pdb_file=None, cont_file=None, ignore_errors=False)[source]¶ Generates inputs for an MD simulation with Q (Qdyn).
Parameters: - relax_proc_file (string) – genrelax procedure file pathname
- outdir (string) – output directory
- restraint (string) – restraint coordinate (a)
- Optional arguments (b)
- top_file (string): Q topology pathname fep_file (string): fep file pathname runscript_file (string): slurm/sge run script pdb_file (string): pdb pathname (used to convert placeholders) cont_file (string): pathname of previous Qdyn input (continuation) ignore_errors (boolean): passed to QStruct and QDynInp - write to logger instead of raising exceptions on non-critical things
(a) Restraint coordinate can be set to: ‘top’ - topology ‘cont_inp’ - whatever is defined in cont_file ‘cont_final’ - endpoint of previous simulation (final restart of cont_file)
- top_file and cont_file are mutually exclusive, one of them has to be provided
Qpyl.qgroupcontrib module¶
This module contains the QGroupContrib class for calculating LRA group contributions. It also defines a custom exception class - QGroupContribError.
-
class
Qpyl.qgroupcontrib.
QGroupContrib
(qcalc_exec, calcdirs, pdb_file, en_list_fn, lambdas_A, lambdas_B, resid_first, resid_last, scale_ionized, nthreads, qmask=None)[source]¶ Bases:
object
Class for calculating LRA group contributions from EVB trajectories.
Parameters: - qcalc_exec (string) – path of qcalc executable
- calcdirs (list of strings) – list of directories
- pdb_file (string) – PDB created with qprep
- en_list_fn (string) – energy-files-list filename
- lambdas_A (tuple of floats) – lambdas of state A (1.0, 0.0)
- lambdas_B (tuple of floats) – lambdas of state B (0.5, 0.5)
- resid_first (int) – index of first residue used for calcs
- resid_last (int) – index of last residue used for calcs
- scale_ionized (float) – scale down ionized residues (ARG, LYS, HIP, GLU, ASP) by this factor (see doi:10.1021/jp962478o)
- nthreads (int) – number of threads
- qmask (list of ints) – list of atom indexes to be used as the Q mask for the GC calculations. By default, this is obtained from the FEP file.
-
details
¶
-
get_pdbgc
()[source]¶ Return the structure in PDB format (string) with added GC values.
Fill the Occupancy fields with LRA contributions and Temperature factor fields with REORG contributions.
-
plotdata
¶ Return GC data as a dictionary of PlotData objects.
- Example keys in returned dictionary:
- ‘gc_lra_el’: PlotData of electrostatic LRA group contributions,
- one subplot - means vs residue index
- ‘gc_lra_el_top’: PlotData of top 20 electrostatic LRA GCs
- one subplot - means vs “resid.resname”
- ‘gc_lra_vdw’: PlotData of vdw LRA GCs,
- one subplot - means vs residue indexes
- ‘gc_reorg_el’: PlotData of el. ‘REORG’ group contributions,
- one subplot - means vs residue index
- ‘gc_de1_el’: PlotData of electrostatic <E1 - E2>_1,
- one subplot - means vs residue index
- ‘gc_de2_el’: PlotData of electrostatic <E1 - E2>_2,
- one subplot - means vs residue index
Qpyl.qmakefep module¶
This module contains the make_fep() function for generating Q FEP-files, and implements a custom exception class QMakeFepError.
-
Qpyl.qmakefep.
make_fep
(qmap_file, pdb_file, forcefield, parm_files, lib_files, ignore_errors=False)[source]¶ Generate a template FEP file for EVB simulations in Q.
Parses a QMAP file (see below), state 1 structure file (PDB) and all states libraries and parameters, and determines the changes in connectivity/charges/parameters that occur between the states.
QMAP is a text file that defines mappings of library ids (for each state) to state 1 structure/topology ids, best explained on an example:
q 315.O OHH.O OHH.O q 315.H1 OHH.H1 HIP.HE2 q 315.H2 OHH.H2 OHH.H2 q 155.NE2 HID.NE2 HIP.NE2 ... n 155.CA HID.CA HIP.CA
The first column defines the atom as being a ‘Q’ atom or a ‘neighbouring’ atom. The latter will not be included in the ‘Q-region’ but will be included in the ‘change_bonds/change_angles...’ sections in case there is a change in bonding/parameters outside the Q region. Additionally, you can define a ‘q’ atom with ‘q_qcp’, which will create an additional section for isotopically clean masses used in QCP calculations. The second column is the PDB ID, comprised of residue index and atom name, separated by a dot. The third column is the library ID of this atom in state 1, comprised of residue name and atom name (should be the same as in the structure). The fourth column is the library ID of this atom in state 2. Additional columns can be added for other states.
The returned template string contains several missing parts, denoted with <FIX>, which have to be manually replaced with appropriate values. These include the softpair C parameters, Morse parameters, Hij parameters.
Parameters: - qmap_file (string) – QMAP file path
- pdb_file (string) – state 1 PDB file path (the one built with qprep)
- forcefield (string) – forcefield type (see SUPPORTED_FF)
- prms_files (list) – Q parameter-file paths
- libs_files (list) – Q library-file paths
- ignore_errors (boolean, optional) – don’t fail on certain non critical errors
Returns: fepfile template
Return type: fepstr (string)
Raises:
Qpyl.qmapping module¶
This module contains the QMapper class for automating the calculation and calibration of EVB reaction free profiles (via Qfep).
-
class
Qpyl.qmapping.
QMapper
(qfep_exec, mapdirs, en_list_fn, hij, alpha, temperature, gas_const, points_skip, gap_bins, minpts_bin, nthreads)[source]¶ Bases:
object
‘Maps’ EVB simulations in specified directories.
Basically a wrapper around Qpyl.qfep.QFep
At the moment, supports only: - 2 states - no predefined Hij - single, constant Hij (mu=eta=r0 = 0)
Parameters: - qfep_exec (string) – qfep executable path
- mapdirs (list of strings) – list of directories
- en_list_fn (string) – energy-files-list filename
- hij (float) – H12_A offdiagonal constant
- alpha (float) – state2 alpha shift
- temperature (float) – temperature in Kelvin
- gas_const (float) – gas_constant in kcal/mol/K
- points_skip (int) – number of energy points to skip in each frame
- gap_bins (int) – number of gap-bins
- minpts_bin (int) – minimum number of points per bin
- nthreads (int) – number of threads
QMapper.parms contains mapping parameters, any direct change will be applied in the mapping. QMapper.mapped contains the inputs and outputs of succesfully mapped dirs # { ‘directory_path1’: (qfep_input_string, qfep_output_string), ... } QMapper.failed contains the error messages of failed dirs # { ‘directory_path2’: ‘error_message’, ... }
QMapper.mapall() maps the directories and updates .mapped and .failed QMapper.fit_to_reference() fits and updates ‘hij’ and ‘alpha’ parameters
-
details
¶
-
fit_to_reference
(dga_ref, dg0_ref, step_size=10.0, threshold=0.005, max_iterations=10)[source]¶ Fit Hij and alpha to obtain desired dG* and dG0 values.
Updates ‘hij’ and ‘alpha’ parameters.
Parameters: - dga_ref (float) – reference activation free energy
- dg0_ref (float) – reference reaction free energy
- step_size (float, optional) – step size for calculating the gradient, default=10.0
- threshold (float, optional) – convergence threshold, default=0.005
- max_iterations (int, optional) – max number of iterations, default=10
Returns: True if succeeded, False if max_iterations was reached.
Return type: (boolean)
Raises QMapperError if all of the directories fail to map.
-
input_parms_str
¶


Based on the analysis of your twitter data, Our Watson Suggest you to choose Investment.
Watson Suggestion on Investments is:
Select the type of investment you want to make
You have selected Investment.


Baby Standen Info
To make sure
everyone
is updated with baby info, we are creating a mailing list.
Sign up below to make sure you get all the information as it happens.
Subscribe to emails
Email
Sign up to Emails!


There are many things that I have as hobbies or have been interested in throughout my life. From hot rods and cruze-ins, computer building, archery, theater arts, engineering, the great outdoors, to comedy, disc golf, dogs (and many other pets), museums and art, and much much more! The most difficult thing for me is to try to just be interested in one thing. With a world that we live in, and with so much to explore and entertain our minds with, why should we?


|
BUILDING AND CIVIL ENGINEERING |
||
|
Baran Serhii, Bilobrytska Olena, Bondar Viktor, Kutsman Oleksandr, Shevchuk Lyudmila |
||
|
11 |
||
|
Lytvynenko Anatoаlii S., Alieksieienko Oleksandr V. |
||
|
Assessment of physical and mechanical indicators of sandy soils by static and dynamic probing data |
18 | |
|
Marchuk Alexander V., Levkivskiy Sergii A., Gavrilenko Elena V. |
|
|
|
26 |
||
|
Shuliak Ivan S., Sukhonosov Serhii O., Chechuha Oleksand S. |
||
|
The development of stamp points displacement mathematical model by static tests of road structures |
35 |
|
|
GEODESY AND LAND MANAGEMENT |
||
|
Kuzminets Nikolai P., Dubovenko Yurii I. |
||
|
44 |
||
|
Liashenko D.O., Pavlyuk D.O. |
|
|
| Geodesic technologies for spatial data collecting for highways diagnostics and certification |
51 |
|
|
Neizvestna Natalia, Khomiak Anna, Omelchuk Sibilla., Malko Marya M |
||
| Investigation of the influence of surfaces between basic stations and satisfactory recognition on the accuracy of coordinating definitions |
60 |
|
|
HYDROTECHNICAL CONSTRUCTION, WATER ENGINEERING AND WATER TECHNOLOGY |
||
|
Gameliak I., Rutkovska I., Herasimenko A., Filishchuk M. |
||
|
69 |
||
|
Snytko Valerii P. |
||
|
84 |
||
|
ENVIRONMENTAL PROTECTION TECHNOLOGY; ECOLOGY |
||
|
Artemenko Vladislav A., Petrovych Volodymyr V. |
||
|
Features of the application of the method of quantile regression in problems of hydroecology |
90 |
|
|
Bondarenko Liudmyla P., Kushnirova Oksana M. |
||
|
Research of environmental risk factors in estimation of real estate |
99 |
|
|
Kondratenko Vadym, Ovsyuk Oleksandra, Oproshchenko Irina, Khomiak Valeria, Khambir Bohdan |
||
|
Environmental protection technology using of waste glass in road construction |
108 |
|
|
SYSTEM ANALYSIS |
||
|
Gameliak Ihor P., Vakarchuk Ihor M., Ivanova Oleksandra O. |
||
|
115 |
||
|
Gusev Alexander V., Rutkovskaya Innesa A., Gerasimenko Alla V |
|
|
|
|
Mathematical model of road traffic accident development using the system analysis theory |
136 |
|
Popelysh Ivan I., Kaskiv Volodymyr I. |
||
|
System approach to aerodrome’s to provision to safety flight |
144 |
|
|
TRANSPORT TECHNOLOGY (BY TYPE) |
||
|
Gusiev O.V., Fedorenko I.О. |
||
|
152 |
||
|
Dodukh Kateryna M., Palchyk Anton D. |
||
|
158 |
||
|
Petrashevskyi Oleh L., Popelish Ivan I., Alieksieienko Oleksandr V., Koritchuk Sergey O., Artemchuk Yuliia V. |
||
|
Proposals for improving of transport systemological terminology (part 5) |
165 | |
|
Sokolenko Tetiana V. |
||
|
180 |
||
|
BRANCH MECHANICAL ENGINEERING |
||
|
Nazarenko Ivan I., Kuzminets Mykola P., Dedov Oleg P., Zalіsko Igor I. |
||
|
188 |
||
|
ECONOMICS, ACCOUNTING AND TAXATION; MANAGEMENT, MARKETING; PIDPRYUMNSTVO, TRADE AND BIRZHOVA ACTIVITY |
||
|
Grechan A.P., Yatsenko B.I., Petrovich V.V., Usychenko O. |
|
|
|
197 |
||
|
Lykhostup M.М. |
||
|
211 |
||
| Slavinska Olena S., Radzinska Yuliya B. | ||
|
Determination of factors affecting investment privalovs land cities |
218 |
|
|
Kharchenko Anna N., Kotyk Daria V. |
|
|
|
Development of algorithm for risk assessment of the large ring road construction project around Kyiv |
225 |
|
|
Yatsenko Ihor V., Kaskiv Volodymyr I., Chechuha Oleksand S. |
||
|
233 |


AAMAS 2018, Stockholm
AAMAS (International Conference on Autonomous Agents and Multiagent Systems) 2018, the 17th edition of the conference, will be held on July 10-15, in Stockholm, Sweden and is part of the Federated AI Meeting (FAIM), with the other conferences being IJCAI, ICML, ICCBR and SoCS. More information available here. The detailed schedule for Yochan’s participation in various tracks and events is given below.
Accepted Papers
-
Recognizing Plans by Learning Embeddings from Observed Action Distributions
Authors - Yantian Zha, Yikang Li, Sriram Gopalakrishnan, Baoxin Li, Subbarao Kambhampati
Abstract - Plan recognition is essential for multi-agent collaboration, and especially for surveillance, in which the agent needs to detect or predict the actions of a perpetrator. Solving the plan recognition problem has been popular in the planning literature [8, 11]. For plan recognition, there is a fair amount of work that uses models with various levels of completeness, i.e. with no model, shallow models, approximate models, and with full models [4]. We adopt the idea of using a shallow model to do plan recognition, and extend the work of DUP [13]. We chose to enhance DUP because it does not require an accurate domain model. DUP learns Word2Vec models which capture affinities between actions (we refer to these models as action affinity models in the rest of our paper), which are then used in plan recognition.
Status - Extended Abstract accepted for the Main Track Event.
Poster Presentation Schedule - 11th July 2018 (15:30 - 17:00)
-
Balancing Explicability and Explanations - Emergent Behaviors in Human-Aware Planning
Authors - Tathagata Chakraborti, Sarath Sreedharan, Subbarao Kambhampati
Abstract - Human aware planning requires an agent to be aware of the intentions, capabilities and mental model of the human in the loop during its decision process. This can involve generating plans that are explicable to a human observer as well as the ability to provide explanations when such plans cannot be generated. In this paper, we bring these two concepts together and show how an agent can account for both these needs and achieve a trade-off during the plan generation process itself by means of a model-space search method MEGA. This in effect provides a comprehensive perspective of what it means for a decision-making agent to be “human-aware” by bringing together existing principles of planning under the umbrella of a single plan generation process. We situate our discussion in the context of recent work on explicable planning and explanation generation, and illustrate these concepts in modified versions of two well-known planning domains, as well as in a demonstration of a robot involved in a typical search and reconnaissance task with an external supervisor. Human factor studies in the latter highlight the usefulness of the proposed approaches.
Status - Extended Abstract accepted for the Robotics Track Event.
Poster Presentation Schedule - 13th July 2018 (15:30 - 17:00)


CSPICE_SINCPT computes the surface intercept of the ray on a target
body at a specified epoch, optionally corrected for light time and stellar
aberration, given an observer and a direction vector defining a ray,
This routine supersedes cspice_srfxpt, which does not have an input
argument for the target body-fixed frame name.
Given:
method a short string providing parameters defining
the computation method to be used. In the syntax
descriptions below, items delimited by brackets
are optional.
[1,c1] = size(method); char = class(method)
or
[1,1] = size(method); cell = class(method)
`method' may be assigned the following values:
'ELLIPSOID'
The intercept computation uses a triaxial
ellipsoid to model the surface of the target
body. The ellipsoid's radii must be available
in the kernel pool.
'DSK/UNPRIORITIZED[/SURFACES = <surface list>]'
The intercept computation uses topographic data
to model the surface of the target body. These
data must be provided by loaded DSK files.
The surface list specification is optional. The
syntax of the list is
<surface 1> [, <surface 2>...]
If present, it indicates that data only for the
listed surfaces are to be used; however, data
need not be available for all surfaces in the
list. If absent, loaded DSK data for any surface
associated with the target body are used.
The surface list may contain surface names or
surface ID codes. Names containing blanks must
be delimited by double quotes, for example
'SURFACES = "Mars MEGDR 128 PIXEL/DEG"'
If multiple surfaces are specified, their names
or IDs must be separated by commas.
See the Particulars section below for details
concerning use of DSK data.
Neither case nor white space are significant in
`method', except within double-quoted strings. For
example, the string " eLLipsoid " is valid.
Within double-quoted strings, blank characters are
significant, but multiple consecutive blanks are
considered equivalent to a single blank. Case is
not significant. So
"Mars MEGDR 128 PIXEL/DEG"
is equivalent to
" mars megdr 128 pixel/deg "
but not to
"MARS MEGDR128PIXEL/DEG"
target the name of the target body. `target' is
case-insensitive, and leading and trailing blanks in
`target' are not significant. Optionally, you may
supply a string containing the integer ID code
for the object. For example both 'MOON' and '301'
are legitimate strings that indicate the moon is the
target body.
[1,c2] = size(target); char = class(target)
or
[1,1] = size(target); cell = class(target)
When the target body's surface is represented by a
tri-axial ellipsoid, this routine assumes that a
kernel variable representing the ellipsoid's radii is
present in the kernel pool. Normally the kernel
variable would be defined by loading a PCK file.
et the epoch, expressed as seconds past J2000 TDB, of the
observer: 'et' is the epoch at which the observer's state
is computed.
[1,1] = size(et); double = class(et)
When aberration corrections are not used, 'et' is also
the epoch at which the position and orientation of the
target body are computed.
When aberration corrections are used, 'et' is the epoch
at which the observer's state relative to the solar
system barycenter is computed; in this case the
position and orientation of the target body are
computed at et-lt or et+lt, where 'lt' is the one-way
light time between the intercept point and the
observer, and the sign applied to 'lt' depends on the
selected correction. See the description of 'abcorr'
below for details.
fixref the name of a body-fixed reference frame centered
on the target body. `fixref' may be any such frame
supported by the SPICE system, including built-in
frames (documented in the Frames Required Reading)
and frames defined by a loaded frame kernel (FK). The
string `fixref' is case-insensitive, and leading and
trailing blanks in `fixref' are not significant.
[1,c3] = size(fixref); char = class(fixref)
or
[1,1] = size(fixref); cell = class(fixref)
The output intercept point `spoint' and the observer-to-
intercept vector `srfvec' will be expressed relative to
this reference frame.
abcorr the aberration correction to apply when computing the
observer-target state and the orientation of the target body.
[1,c4] = size(abcorr); char = class(abcorr)
or
[1,1] = size(abcorr); cell = class(abcorr)
'abcorr' may be any of the following.
"NONE" Apply no correction. Return the
geometric surface intercept point on the
target body.
Let 'lt' represent the one-way light time between the
observer and the surface intercept point (note: NOT
between the observer and the target body's center).
The following values of 'abcorr' apply to the
"reception" case in which photons depart from the
intercept point's location at the light-time
corrected epoch et-lt and *arrive* at the observer's
location at 'et':
"LT" Correct for one-way light time (also
called "planetary aberration") using a
Newtonian formulation. This correction
yields the location of the surface
intercept point at the moment it
emitted photons arriving at the
observer at 'et'.
The light time correction uses an
iterative solution of the light time
equation. The solution invoked by the
"LT" option uses one iteration.
Both the target state as seen by the
observer, and rotation of the target
body, are corrected for light time.
"LT+S" Correct for one-way light time and
stellar aberration using a Newtonian
formulation. This option modifies the
state obtained with the "LT" option to
account for the observer's velocity
relative to the solar system
barycenter. The result is the apparent
surface intercept point as seen by the
observer.
"CN" Converged Newtonian light time
correction. In solving the light time
equation, the "CN" correction iterates
until the solution converges. Both the
state and rotation of the target body
are corrected for light time.
"CN+S" Converged Newtonian light time
and stellar aberration corrections.
The following values of 'abcorr' apply to the
"transmission" case in which photons *depart* from
the observer's location at 'et' and arrive at the
intercept point at the light-time corrected epoch
ET+LT:
"XLT" "Transmission" case: correct for
one-way light time using a Newtonian
formulation. This correction yields the
intercept location at the moment it
receives photons emitted from the
observer's location at 'et'.
The light time correction uses an
iterative solution of the light time
equation. The solution invoked by the
"LT" option uses one iteration.
Both the target state as seen by the
observer, and rotation of the target
body, are corrected for light time.
"XLT+S" "Transmission" case: correct for
one-way light time and stellar
aberration using a Newtonian
formulation This option modifies the
intercept obtained with the "XLT"
option to account for the observer's
velocity relative to the solar system
barycenter.
"XCN" Converged Newtonian light time
correction. This is the same as XLT
correction but with further iterations
to a converged Newtonian light time
solution.
"XCN+S" "Transmission" case: converged
Newtonian light time and stellar
aberration corrections.
Case and embedded blanks are not significant in 'abcorr'.
obsrvr the name of the observing body. This is typically
a spacecraft, the earth, or a surface point on the earth.
[1,c5] = size(obsrvr); char = class(obsrvr)
or
[1,1] = size(obsrvr); cell = class(obsrvr)
'obsrvr' is case-insensitive, and leading and
trailing blanks in 'obsrvr' are not significant.
Optionally, you may supply a string containing the
integer ID code for the object. For example both
"MOON" and "301" are legitimate strings that indicate
the moon is the observer.
dref the name of the reference frame relative to which
the ray's direction vector is expressed. This may be
any frame supported by the SPICE system, including
built-in frames (documented in the Frames Required
Reading) and frames defined by a loaded frame kernel
(FK). The string `dref' is case-insensitive, and
leading and trailing blanks in `dref' are not
significant.
[1,c6] = size(dref); char = class(dref)
or
[1,1] = size(dref); cell = class(dref)
When `dref' designates a non-inertial frame, the
orientation of the frame is evaluated at an epoch
dependent on the frame's center and, if the center is
not the observer, on the selected aberration
correction. See the description of the direction
vector `dvec' for details.
dvec the pointing vector emanating from the observer. The
intercept with the target body's surface of the ray
defined by the observer and 'dvec' is sought.
[3,1] = size(dvec); double = class(dvec)
'dvec' is specified relative to the reference frame
designated by 'dref'.
Non-inertial reference frames are treated as follows:
if the center of the frame is at the observer's
location, the frame is evaluated at 'et'. If the
frame's center is located elsewhere, then letting
'ltcent' be the one-way light time between the observer
and the central body associated with the frame, the
orientation of the frame is evaluated at et-ltcent,
et+ltcent, or 'et' depending on whether the requested
aberration correction is, respectively, for received
radiation, transmitted radiation, or is omitted.
'ltcent' is computed using the method indicated by
'abcorr'.
the call:
[ spoint, trgepc, srfvec, found] = cspice_sincpt( method, target, ...
et, fixref, ...
abcorr, obsrvr, ...
dref, dvec)
returns:
spoint the surface intercept point on the target body of the ray
defined by the observer and the direction vector. If the ray
intersects the target body in multiple points, the selected
intersection point is the one closest to the observer. The
output argument 'found' (see below) indicates whether an
intercept was found.
[3,1] = size(spoint); double = class(spoint)
'spoint' is expressed in Cartesian coordinates,
relative to the target body-fixed frame designated by
FIXFRM. The body-fixed target frame is evaluated at
the intercept epoch 'trgepc' (see description below).
When light time correction is used, the duration of
light travel between 'spoint' to the observer is
considered to be the one way light time. When both
light time and stellar aberration corrections are
used, 'spoint' is selected such that, when 'spoint' is
corrected for light time and the vector from the
observer to the light-time corrected location of
'spoint' is corrected for stellar aberration, the
resulting vector is parallel to the ray defined by
the observer's location and 'dvec'.
The components of 'spoint' are given in units of km.
trgepc the "intercept epoch."
[1,1] = size(trgepc); double = class(trgepc)
This is the epoch at which the ray defined by 'obsrvr'
and 'dvec' intercepts the target surface at 'spoint'.
'trgepc' is defined as follows: letting 'lt' be the one-way
light time between the observer and the intercept point,
'trgepc' is the epoch et-lt, et+lt, or 'et' depending on
whether the requested aberration correction is, respectively,
for received radiation, transmitted radiation, or
omitted. 'lt' is computed using the method indicated by
'abcorr'.
'trgepc' is expressed as seconds past J2000 TDB.
srfvec the vector from the observer's position at 'et' to
'spoint'. 'srfvec' is expressed in the target body-fixed
reference frame designated by 'fixref', evaluated at
'trgepc'.
[3,1] = size(srfvec); double = class(srfvec)
The components of 'srfvec' are given in units of km.
One can use the CSPICE function cspice_vnorm to obtain the
distance between the observer and 'spoint':
dist = norm( srfvec )
The observer's position 'obspos', relative to the
target body's center, where the center's position is
corrected for aberration effects as indicated by
'abcorr', can be computed with:
obspos = spoint - srfvec
To transform the vector 'srfvec' from a reference frame
'fixref' at time 'trgepc' to a time-dependent reference
frame 'ref' at time 'et', call the routine 'cspice_pxfrm2'.
Let 'xform' be the 3x3 matrix representing the
rotation from the reference frame 'fixref' at time
'trgepc' to the reference frame 'ref' at time 'et'. Then
'srfvec' can be transformed to the result 'refvec' as
follows:
xform = cspice_pxfrm2 ( fixref, ref, trgepc, et )
refvec = xform * srfvec
found a flag indicating whether or not the ray
intersects the target. If an intersection exists
'found' will return true If the ray misses
the target, 'found' will return false.
[1,1] = size(found); logical = class(found)
Any numerical results shown for this example may differ between
platforms as the results depend on the SPICE kernels used as input
and the machine specific arithmetic implementation.
The following program computes surface intercept points on
Mars for the boresight and FOV boundary vectors of the MGS MOC
narrow angle camera. The intercepts are computed for a single
observation epoch. Light time and stellar aberration corrections
are used. For simplicity, camera distortion is ignored.
%
% Local variables
%
abcorr = 'CN+S';
camera = 'MGS_MOC_NA';
fixref = 'IAU_MARS';
method = 'Ellipsoid';
obsrvr = 'MGS';
target = 'Mars';
utc = '2003 OCT 13 06:00:00 UTC';
NCORNR = 4;
%
% Load kernel files.
%
cspice_furnsh( 'standard.tm' );
cspice_furnsh( { '/kernels/MGS/ik/moc20.ti', ...
'/kernels/MGS/sclk/MGS_SCLKSCET.00061.tsc' ,...
'/kernels/MGS/spk/mgs_ext12_ipng_mgs95j.bsp',...
'/kernels/MGS/ck/mgs_sc_ext12.bc' } )
%
% Convert the UTC request time to ET (seconds past
% J2000, TDB).
%
et = cspice_str2et( utc );
%
% Get the MGS MOC Narrow angle camera (MGS_MOC_NA)
% ID code. Then look up the field of view (FOV)
% parameters.
%
[ camid, found ] = cspice_bodn2c( camera );
if ( ~found )
txt = sprintf( [ 'SPICE(NOTRANSLATION) ' ...
'Could not find ID code for instrument %s.' ], ...
camera);
error( txt )
end
%
% cspice_getfov will return the name of the camera-fixed frame
% in the string 'dref', the camera boresight vector in
% the array 'bsight', and the FOV corner vectors in the
% array 'bounds'.
%
[shape, dref, bsight, bounds] = cspice_getfov( camid, NCORNR);
fprintf ( ['\n' ...
'Surface Intercept Locations for Camera\n' ...
'FOV Boundary and Boresight Vectors\n' ...
'\n' ...
' Instrument: %s\n' ...
' Epoch: %s\n' ...
' Aberration correction: %s\n' ...
'\n'], ...
camera, utc, abcorr )
for i=1:NCORNR+1
if( i <= NCORNR )
fprintf( 'Corner vector %d\n\n', i)
dvec = bounds(:,i);
end
if ( i == (NCORNR + 1) )
fprintf( 'Boresight vector\n\n' )
dvec = bsight;
end
%
% Compute the surface intercept point using
% the specified aberration corrections.
%
[ spoint, trgepc, srfvec, found ] = ...
cspice_sincpt( method, target, ...
et, fixref, abcorr, ...
obsrvr, dref, dvec );
if( found )
%
% Compute range from observer to apparent intercept.
%
dist = vnorm( srfvec );
%
% Convert rectangular coordinates to planetocentric
% latitude and longitude. Convert radians to degrees.
%
[ radius, lon, lat ] = cspice_reclat( spoint );
lon = lon * cspice_dpr;
lat = lat * cspice_dpr;
%
% Display the results.
%
fprintf( ' Vector in %s frame = \n', dref )
fprintf( ' %18.10e %18.10e %18.10e\n', dvec );
fprintf( [ '\n' ...
' Intercept:\n' ...
'\n' ...
' Radius (km) = %18.10e\n' ...
' Planetocentric Latitude (deg) = %18.10e\n' ...
' Planetocentric Longitude (deg) = %18.10e\n' ...
' Range (km) = %18.10e\n' ...
'\n' ], ...
radius, lat, lon, dist )
else
disp( 'Intercept not found.' )
end
end
%
% It's always good form to unload kernels after use,
% particularly in MATLAB due to data persistence.
%
cspice_kclear
MATLAB outputs:
Surface Intercept Locations for Camera
FOV Boundary and Boresight Vectors
Instrument: MGS_MOC_NA
Epoch: 2003 OCT 13 06:00:00 UTC
Aberration correction: CN+S
Corner vector 1
Vector in MGS_MOC_NA frame =
1.8571383810e-06 -3.8015622659e-03 9.9999277403e-01
Intercept:
Radius (km) = 3.3849411359e+03
Planetocentric Latitude (deg) = -4.8477481924e+01
Planetocentric Longitude (deg) = -1.2347407905e+02
Range (km) = 3.8898310366e+02
Corner vector 2
Vector in MGS_MOC_NA frame =
1.8571383810e-06 3.8015622659e-03 9.9999277403e-01
Intercept:
Radius (km) = 3.3849396987e+03
Planetocentric Latitude (deg) = -4.8481636340e+01
Planetocentric Longitude (deg) = -1.2339882297e+02
Range (km) = 3.8897512129e+02
Corner vector 3
Vector in MGS_MOC_NA frame =
-1.8571383810e-06 3.8015622659e-03 9.9999277403e-01
Intercept:
Radius (km) = 3.3849396899e+03
Planetocentric Latitude (deg) = -4.8481661910e+01
Planetocentric Longitude (deg) = -1.2339882618e+02
Range (km) = 3.8897466238e+02
Corner vector 4
Vector in MGS_MOC_NA frame =
-1.8571383810e-06 -3.8015622659e-03 9.9999277403e-01
Intercept:
Radius (km) = 3.3849411271e+03
Planetocentric Latitude (deg) = -4.8477507498e+01
Planetocentric Longitude (deg) = -1.2347408220e+02
Range (km) = 3.8898264472e+02
Boresight vector
Vector in MGS_MOC_NA frame =
0.0000000000e+00 0.0000000000e+00 1.0000000000e+00
Intercept:
Radius (km) = 3.3849404102e+03
Planetocentric Latitude (deg) = -4.8479579822e+01
Planetocentric Longitude (deg) = -1.2343645396e+02
Range (km) = 3.8897573572e+02
Given a ray defined by a direction vector and the location of an
observer, cspice_sincpt computes the surface intercept point of the ray
on a specified target body. cspice_sincpt also determines the vector
from the observer to the surface intercept point. If the ray
intersects the target in multiple locations, the intercept
closest to the observer is selected.
When aberration corrections are used, this routine finds the
value of `spoint' such that, if `spoint' is regarded as an ephemeris
object, after the selected aberration corrections are applied to
the vector from the observer to `spoint', the resulting vector is
parallel to the direction vector `dvec'.
This routine computes light time corrections using light time
between the observer and the surface intercept point, as opposed
to the center of the target. Similarly, stellar aberration
corrections done by this routine are based on the direction of
the vector from the observer to the light-time corrected
intercept point, not to the target center. This technique avoids
errors due to the differential between aberration corrections
across the target body. Therefore it's valid to use aberration
corrections with this routine even when the observer is very
close to the intercept point, in particular when the
observer-intercept point distance is much less than the
observer-target center distance. It's also valid to use stellar
aberration corrections even when the intercept point is near or
on the limb (as may occur in occultation computations using a
point target).
When comparing surface intercept point computations with results
from sources other than SPICE, it's essential to make sure the
same geometric definitions are used.
Using DSK data
==============
DSK loading and unloading
-------------------------
DSK files providing data used by this routine are loaded by
calling cspice_furnsh and can be unloaded by calling cspice_unload or
cspice_kclear. See the documentation of cspice_furnsh for limits on
numbers of loaded DSK files.
For run-time efficiency, it's desirable to avoid frequent
loading and unloading of DSK files. When there is a reason to
use multiple versions of data for a given target body---for
example, if topographic data at varying resolutions are to be
used---the surface list can be used to select DSK data to be
used for a given computation. It is not necessary to unload
the data that are not to be used. This recommendation presumes
that DSKs containing different versions of surface data for a
given body have different surface ID codes.
DSK data priority
-----------------
A DSK coverage overlap occurs when two segments in loaded DSK
files cover part or all of the same domain---for example, a
given longitude-latitude rectangle---and when the time
intervals of the segments overlap as well.
When DSK data selection is prioritized, in case of a coverage
overlap, if the two competing segments are in different DSK
files, the segment in the DSK file loaded last takes
precedence. If the two segments are in the same file, the
segment located closer to the end of the file takes
precedence.
When DSK data selection is unprioritized, data from competing
segments are combined. For example, if two competing segments
both represent a surface as a set of triangular plates, the
union of those sets of plates is considered to represent the
surface.
Currently only unprioritized data selection is supported.
Because prioritized data selection may be the default behavior
in a later version of the routine, the UNPRIORITIZED keyword is
required in the `method' argument.
Syntax of the `method' input argument
-----------------------------------
The keywords and surface list in the `method' argument
are called "clauses." The clauses may appear in any
order, for example
'DSK/<surface list>/UNPRIORITIZED'
'DSK/UNPRIORITIZED/<surface list>'
'UNPRIORITIZED/<surface list>/DSK'
The simplest form of the `method' argument specifying use of
DSK data is one that lacks a surface list, for example:
'DSK/UNPRIORITIZED'
For applications in which all loaded DSK data for the target
body are for a single surface, and there are no competing
segments, the above string suffices. This is expected to be
the usual case.
When, for the specified target body, there are loaded DSK
files providing data for multiple surfaces for that body, the
surfaces to be used by this routine for a given call must be
specified in a surface list, unless data from all of the
surfaces are to be used together.
The surface list consists of the string
'SURFACES = '
followed by a comma-separated list of one or more surface
identifiers. The identifiers may be names or integer codes in
string format. For example, suppose we have the surface
names and corresponding ID codes shown below:
Surface Name ID code
------------ -------
"Mars MEGDR 128 PIXEL/DEG" 1
"Mars MEGDR 64 PIXEL/DEG" 2
"Mars_MRO_HIRISE" 3
If data for all of the above surfaces are loaded, then
data for surface 1 can be specified by either
'SURFACES = 1'
or
'SURFACES = "Mars MEGDR 128 PIXEL/DEG"'
Double quotes are used to delimit the surface name because
it contains blank characters.
To use data for surfaces 2 and 3 together, any
of the following surface lists could be used:
'SURFACES = 2, 3'
'SURFACES = "Mars MEGDR 64 PIXEL/DEG", 3'
'SURFACES = 2, Mars_MRO_HIRISE'
'SURFACES = "Mars MEGDR 64 PIXEL/DEG", Mars_MRO_HIRISE'
An example of a `method' argument that could be constructed
using one of the surface lists above is
'DSK/UNPRIORITIZED/SURFACES = "Mars MEGDR 64 PIXEL/DEG", 3'
Round-off errors and mitigating algorithms
------------------------------------------
When topographic data are used to represent the surface of a
target body, round-off errors can produce some results that
may seem surprising.
Note that, since the surface in question might have mountains,
valleys, and cliffs, the points of intersection found for
nearly identical sets of inputs may be quite far apart from
each other: for example, a ray that hits a mountain side in a
nearly tangent fashion may, on a different host computer, be
found to miss the mountain and hit a valley floor much farther
from the observer, or even miss the target altogether.
Round-off errors can affect segment selection: for example, a
ray that is expected to intersect the target body's surface
near the boundary between two segments might hit either
segment, or neither of them; the result may be
platform-dependent.
A similar situation exists when a surface is modeled by a set
of triangular plates, and the ray is expected to intersect the
surface near a plate boundary.
To avoid having the routine fail to find an intersection when
one clearly should exist, this routine uses two "greedy"
algorithms:
1) If the ray passes sufficiently close to any of the
boundary surfaces of a segment (for example, surfaces of
maximum and minimum longitude or latitude), that segment
is tested for an intersection of the ray with the
surface represented by the segment's data.
This choice prevents all of the segments from being
missed when at least one should be hit, but it could, on
rare occasions, cause an intersection to be found in a
segment other than the one that would be found if higher
precision arithmetic were used.
2) For type 2 segments, which represent surfaces as
sets of triangular plates, each plate is expanded very
slightly before a ray-plate intersection test is
performed. The default plate expansion factor is
1 + 1.e-10
In other words, the sides of the plate are lengthened by
1/10 of a micron per km. The expansion keeps the centroid
of the plate fixed.
Plate expansion prevents all plates from being missed
in cases where clearly at least one should be hit.
As with the greedy segment selection algorithm, plate
expansion can occasionally cause an intercept to be
found on a different plate than would be found if higher
precision arithmetic were used. It also can occasionally
cause an intersection to be found when the ray misses
the target by a very small distance.
Aberration corrections
----------------------
For irregularly shaped target bodies, the distance between the
observer and the nearest surface intercept need not be a
continuous function of time; hence the one-way light time
between the intercept and the observer may be discontinuous as
well. In such cases, the computed light time, which is found
using iterative algorithm, may converge slowly or not at all.
In all cases, the light time computation will terminate, but
the result may be less accurate than expected.
For important details concerning this module's function, please refer to
the CSPICE routine sincpt_c.
MICE.REQ
DSK.REQ
FRAMES.REQ
NAIF_IDS.REQ
PCK.REQ
SPK.REQ
TIME.REQ
-Mice Version 2.0.0, 04-APR-2017, EDW (JPL), NJB (JPL)
Header update to reflect support for use of DSKs.
Edited I/O section to conform to NAIF standard for Mice documentation.
-Mice Version 1.0.3, 12-MAR-2012, SCK (JPL)
References to the new 'cspice_pxfrm2' routine were
added to the 'I/O returns' section. A problem description was
added to the 'Examples' section, and the references to
'cspice_srfxpt' and the second example were removed.
-Mice Version 1.0.2, 14-JUL-2010, EDW (JPL)
Corrected minor typo in header.
-Mice Version 1.0.1, 23-FEB-2009, EDW (JPL)
Added proper markers for usage string variable types.
-Mice Version 1.0.0, 11-FEB-2008, EDW (JPL)
find surface intercept point
find intersection of ray and target body surface
find intercept of ray on target body surface
|


You must fill out a declaration form for customs and pay any duties on any items that are not Duty Free. Then you will be asked to push a button on a traffic signal.
If you are caught with items not declared or exceeding their reported value without paying duties you are liable for fines of 1 to 3 times the value of those items and they can be confiscated by the authorities.
Foreign and Mexican Residents may bring personal items such as:
Clothing and shoes, in non-commercial quantities
1 Camera, movie or video camera with power supply with up to 12 rolls of film or videocassettes
1 Portable computer (laptop)
1 Piece of used sporting equipment (that can be carried by one person)
Books and magazines, in non commercial quantities
Medicines for personal use (with prescriptions if psychotropic)
Luggage necessary to carry all this
A maximum of 20 packs of cigarettes, 25 cigars or 200 grams of tobacco
Up to 3 liters of wine, beer or liquor
Foreign Residents, in addition to the above, may bring:1 Pair of Binoculars
1 TV under 12 inches
1 portable radio/recorder
2 laser disks
20 CDs or cassette tapes
1 Typewriter
1 Musical instrument (that can be carried by one person)
1 Set of camping gear and tent
5 toys
1 set of fishing gear
1 pair of skis
1 pair of tennis racquets
1 surfboard or sailboard
1 Videocassette recorder
Foods
You may bring vegetables, fruits, flours, dried nuts, spices and milk products for personal use. Fresh and frozen meats and fowl are allowed if they are sealed in their original wrappers with stickers indicating their origin in the U.S. or Canada.Money
Bringing money in any quantity is not a crime but not declaring it can be. You may bring $10.000 U.S. in cash or checks legally but you must declare any funds over that amount. If you bring over $30,000 U.S. you can be sent to prison for up to six years and the federal authorities keep all funds over $20,000 U.S.
Once you pick up your luggage procede to Customs. Declaration must be signed and filled out, introduce it facing up into the laser reader (if returned hand it over to the Customs Officer).
Official site of Mexican Customs http://www.iica.int/sites/default/files/guia_rapida_para_ingresar_a_mexico_6_idiomas.pdf
FORBIDDEN ITEMS TAKEN INTO THE COUNTRY
• Live predatory fish (young or adult).
• Totoaba fish, either fresh, refrigerated or frozen.
• Turtle eggs.
• Poppy seeds.
• Spores or marihuana seeds. Marihuana extracts, either juice, mucilage, or plants, and/or marihuana based medications (Cannabis Indica).
• Juice or extract of opium.
• Stamps, cards or wrapping paper (color or b/w) even on chewing gum, or candy packages with figures or drawings showing denigration messages to childhood, ridicule, violence related, self destruction, or any other sociopath behavior known as “Garbage Pail Kids”
• Thalio sulfates.
• Insecticides of any kind. • Heroine.
• Turtle skin.
• Any good declared as archeologicals by the Secretary of Public Education (SEP).


PLANET SICK-BOY: http://www.sick-boy.com "We Put the SIN in Cinema"
The legend of Max Schreck is ... well, legendary. The unknown actor virtually came from nowhere to land the role of the vampire in the classic 1922 film Nosferatu. According to myth, Schreck wasn't just pretending to be a bloodsucker – he actually was one of the undead. The new film Shadow of the Vampire brings the legend of Schreck to the big screen over 70 years after the creepy actor put his unique stamp on what many consider to be the greatest portrayal of a vampire ever.
But how successful can a film be with no A-list stars, a mediocre actor-turned-producer (Nicolas Cage), a no-name director, a first-time screenwriter, a miniscule running time (most of which seem to be burned during the opening credits) and the presence of Udo Kier? The answer is `moderately." Vampire is a sloppy mess of a film, really corny, and a lot of fun to watch. It also boasts what should be a lock for a Best Supporting Actor nomination at next year's Academy Awards in Willem Dafoe, who plays the spindly Schreck to eerie perfection. Kudos should also be given to the people responsible for transforming Dafoe into Schreck.
John Malkovich (Being John Malkovich) plays Nosferatu director F.W. Murnau, who wanted to make a film based on Bram Stoker's `Dracula,' but Stoker's wife Florence refused to give him permission. Murnau created his own vampire character in Nosferatu, swapping Count Dracula for Count Orlock. His film, which was silent, followed a simple story involving a German real estate agent (played here by Eddie Izzard, Velvet Goldmine) and his fiancée (Catherine McCormack, Dangerous Beauty) who meet up with a potential client in Orlock (Dafoe, American Psycho).
In Vampire, Schreck is presented to the cast and crew of Nosferatu as one of the craft's first method actors. Murnau explains that Schreck will only appear in full costume and makeup, and, because of his kooky requirements, insists they only shoot at night. You don't see Shreck/Orlock until nearly 30 minutes into the film, which, given the running time here, is a significant portion of the movie. But when he finally emerges from the shadows, it's quite startling. Where most screen portrayals of vampires have opted for creating a brooding lady-killer character, Vampire instead shows Schreck/Orlock as a bald, overgrown rat with impossibly long fingernails and gimpy little arms that hang above his chest like a bat.
Vampire mainly shows the trouble Murnau had keeping the bloodthirsty Schreck in line during the filming of Nosferatu. When the cinematographer dies of a mysterious ailment (and two tiny puncture wounds in his neck), Murnau is forced to depart the set to find another cameraman, which leaves Schreck unsupervised with the rest of the film crew. In order to keep Schreck from wreaking total havoc on the set, Murnau promises to `give' the morphine-addicted female lead to Schreck once the filming is completed, provided he behaves himself. The finale is as madcap as you would expect from a success-hungry director, a hophead and a vampire pretending to be an actor pretending to be a vampire.
While most of the Vampire seems haphazardly slapped onto film, it does do a great job recreating the look and feel of a silent film with the use of title cards and the shift from black-and-white to color stock. The story, which was written by debut screenwriter Steven Katz (he penned part one of HBO's From the Earth to the Moon), is unnecessarily messy for a film this length. Vampire was directed by E. Elias Merhige, whose only previous film credit was the 1991 horror flick, Begotten. An interesting note – Max Schreck is the name of the villain in Batman Returns (played by Christopher Walken).
1:31 – R for adult language, nudity, violence
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


public class VersionRange
extends java.lang.Object
| Modifier and Type | Method and Description |
|---|---|
VersionRange |
cloneOf() |
boolean |
containsVersion(ArtifactVersion version) |
static VersionRange |
createFromVersion(java.lang.String version,
ArtifactVersion existing) |
static VersionRange |
createFromVersionSpec(java.lang.String spec)
Create a version range from a string representation
Some spec examples are
1.0 Version 1.0
[1.0,2.0) Versions 1.0 (included) to 2.0 (not included)
[1.0,2.0] Versions 1.0 to 2.0 (both included)
[1.5,) Versions 1.5 and higher
(,1.0],[1.2,) Versions up to 1.0 (included) and 1.2 or
higher
|
boolean |
equals(java.lang.Object obj) |
java.lang.String |
getLowerBoundString() |
ArtifactVersion |
getRecommendedVersion() |
java.util.List<Restriction> |
getRestrictions() |
int |
hashCode() |
boolean |
hasRestrictions() |
boolean |
isUnboundedAbove() |
ArtifactVersion |
matchVersion(java.util.List<ArtifactVersion> versions) |
static VersionRange |
newRange(ArtifactVersion version,
java.util.List<Restriction> restrictions)
Factory method, for custom versioning schemes
|
VersionRange |
restrict(VersionRange restriction)
Creates and returns a new
VersionRange that is a restriction of
this version range and the specified version range. |
java.lang.String |
toString() |
public ArtifactVersion getRecommendedVersion()
public java.util.List<Restriction> getRestrictions()
public VersionRange cloneOf()
public static VersionRange newRange(ArtifactVersion version, java.util.List<Restriction> restrictions)
version
- versionrestrictions
- restriction listpublic static VersionRange createFromVersionSpec(java.lang.String spec) throws InvalidVersionSpecificationException
1.0
Version 1.0[1.0,2.0)
Versions 1.0 (included) to 2.0 (not included)[1.0,2.0]
Versions 1.0 to 2.0 (both included)[1.5,)
Versions 1.5 and higher(,1.0],[1.2,)
Versions up to 1.0 (included) and 1.2 or
higherspec
- string representation of a version or version rangeVersionRange
object that represents the specInvalidVersionSpecificationException
public static VersionRange createFromVersion(java.lang.String version, ArtifactVersion existing)
public VersionRange restrict(VersionRange restriction)
VersionRange
that is a restriction of
this version range and the specified version range.
Note: Precedence is given to the recommended version from this version range over the recommended version from the specified version range.
restriction
- the VersionRange
that will be used to restrict this
version range.VersionRange
that is a restriction of this version
range and the specified version range.
The restrictions of the returned version range will be an intersection of the restrictions of this version range and the specified version range if both version ranges have restrictions. Otherwise, the restrictions on the returned range will be empty.
The recommended version of the returned version range will be the
recommended version of this version range, provided that ranges falls
within the intersected restrictions. If the restrictions are empty,
this version range's recommended version is used if it is not
null
. If it is null
, the specified version
range's recommended version is used (provided it is
non-null
). If no recommended version can be obtained,
the returned version range's recommended version is set to
null
.
java.lang.NullPointerException
- if the specified VersionRange
is null
.public java.lang.String toString()
toString
in class java.lang.Object
public ArtifactVersion matchVersion(java.util.List<ArtifactVersion> versions)
public boolean containsVersion(ArtifactVersion version)
public boolean hasRestrictions()
public boolean equals(java.lang.Object obj)
equals
in class java.lang.Object
public int hashCode()
hashCode
in class java.lang.Object
public boolean isUnboundedAbove()
public java.lang.String getLowerBoundString()


style
<style>
in the head.
<style>
in a second head.
<style>
in the body, before test content.
<style>
in the body, after test content.
<style>
in a second body.


SFSU Software Engineering Project CSC 648-848, Summer 2019. For Demonstration Only
Safe SF
Create Report
About
Admin
Login
Register
Logout


Honoring the Fallen: An Interactive Memorial Map
Paul M. McGrath
- Date of Birth: 08/05/1944
- Home of Record: RYE
- State: NY
- Branch: USMC
- Place of Death: Quang Nam
- Year of Death: 1968
- Villanova Class Year: 1966
- Major: Political Science
- Sports & Clubs at Villanova: Football, Intramural Sports, Conservative Club, Spanish Club, Young Republicans
Paul M. McGrath served during the Vietnam War. He began his tour on December 9, 1967. He had the rank of Second Lieutenant. His occupation or specialty was Infantry Officer and his service number was 0103672. He served 3rd Marine Division, 1st Battalion, 26th Marines, A Company. McGrath experienced a traumatic event which resulted in loss of life on June 7, 1968. Recorded circumstances attributed to: “Died through hostile action, small arms fire”.
The Conspicuous Service Cross may be awarded to any current New York State citizen or person who was a New York State citizen while serving on federal active duty; whose entire service was honorable subsequent to the time of receipt of the citation while serving in the U.S. Army, Air Force, Navy, Marine Corps, Coast Guard or in the Army female nurse corps, and who has received a personal decoration issued by a brigade or equivalent higher headquarters. Paul Martin McGrath was awarded The Conspicuous Service Cross on April 14, 1969.
Works cited
- Paul M. McGrath. HonorStates.org.https://www.honorstates.org/index.php?id=287030
- Paul M. McGrath. Vietnam Veterans Memorial Fund Wall of Faces. https://www.vvmf.org/Wall-of-Faces/36773/PAUL-M-MCGRATH/
- College, V. (1966). Belle Air 1966. Villanova, PA : Villanova College. https://library.villanova.edu/Find/Record/vudl:558997
Cite this article
"Paul M. McGrath." Honoring the Fallen: An Interactive Memorial Map. http://localhost:4000/article/1968-07-06-paulmmcgrath.html


#include <datastruct.h>
Data Fields | |
| long | id |
| char * | uri |
| char * | local_name |
| char * | buddy_lists |
| int | online_status |
| Fetion_Personal * | personal |
| long Fetion_Account::id |
account id.
| char* Fetion_Account::uri |
account uri.
account local_name.
account group id, it store as string, the format is *;*;.
account online status
account personal info.


Swagger-wtforms
example
Examples
Single form
All forms from definitions
{% block body %}{% endblock %}
The spec (
{{ file }}
)
{{ spec }}


Inherited Variables
Inherited Constants
Inherited Methods
Class Details
ServerControl class
Contains all core game server control functionality. Represents a server reservation.
[ Top ]
Class Variables
$gameId
[line 9]
Tags:
- access - public
Type: mixed
Overrides:
[ Top ]
$host
[line 9]
Tags:
- access - public
Type: mixed
Overrides:
[ Top ]
$ip
[line 9]
Tags:
- access - public
Type: mixed
Overrides:
[ Top ]
$map
[line 9]
Tags:
- access - public
Type: mixed
Overrides:
[ Top ]
$maxplayers
[line 9]
Tags:
- access - public
Type: mixed
Overrides:
[ Top ]
$port
[line 9]
Tags:
- access - public
Type: mixed
Overrides:
[ Top ]
$rcon
[line 9]
Tags:
- access - public
Type: mixed
Overrides:
[ Top ]
$serverId
[line 9]
Tags:
- access - public
Type: mixed
Overrides:
[ Top ]
$sid
[line 9]
Tags:
- access - public
Type: mixed
Overrides:
[ Top ]
Class Methods
__construct
ServerControl __construct(
[line 18]
Set up options for the game server instance
Tags:
- access - public
Parameters:
-
$sid - Reservation ID -
$serverId - Server ID -
$gameId - Game identifier -
$rcon - Rcon password
[ Top ]
createCfg
[line 93]
Send configuration files to remote host
Tags:
- return - TRUE on success
- access - public
Parameters:
[ Top ]
prepareCfg
void prepareCfg(
)
[line 68]
Generate local configuration files
Tags:
- access - public
Parameters:
[ Top ]
restart
void restart(
)
[line 134]
Restart the game server
Tags:
- access - public
Parameters:
[ Top ]
send
void send(
[line 110]
Send a command to the game server console
Tags:
- access - public
Parameters:
-
$cmd - Command to send
[ Top ]
start
void start(
)
[line 118]
Start the game server
Tags:
- access - public
Parameters:
[ Top ]
stop
void stop(
)
[line 126]
Stop the game server
Tags:
- access - public
Parameters:
[ Top ]


Hello {{ context.username }},
In accordance with {{ context.organizationName }}'s community guidelines, your
account has been temporarily suspended. During the suspension, you will be
unable to comment, flag or engage with fellow commenters. Please rejoin the
conversation {{ context.until }}.
If you think this has been done in error, please contact our community team at
{{ context.organizationContactEmail }}.
{% endblock %}


Mike Hodnick / @kindohm kindohm.github.io/space150-livecoding
Programmer / noise-maker
Change a running program in real time.
.com, gmail, fb, twitter, snapchat, bandcamp, soundcloud


Some basic information about this site -- my goals and how to contact me if you'd like to do so.
Visualize the waveform and spectrum of web audio api oscilators using d3.


Our program at Wisdom360 guides kids through the steps of building their own business while introducing them to the exciting world of entrepreneurship and enhancing their workplace readiness, regardless of future career choices. Children are introduced to the world of entrepreneurship in a fun and engaging way – by starting their own business! Kids learn all the business basics, along with valuable life skills, as they prepare to sell their products or service.

Understand the concepts of entrepreneurship.
Brainstorm business ideas
Create a simple business plan with a budget
Devise and implement a simple marketing plan
Entrepreneurship in easy & fun ways
Provide students with the psychological benefits of ownership and empowerment so that vital business and life skills emerge
Show kids how their core academic learning applies to the world around them
UNDERSTANDING BUSINESS AND AN ENTREPRENEUR?
Why startup up your own business? Who is an entrepreneur?
HOW TO FIND PROBLEMS IN A BUSINESS?
Building a product and identify problems in a business and find the right opportunity to solve it
BUILDING A TEAM
Find the right fit of people for your team and build it
CREATE A BUSINESS PLAN
Ways to create a business plan for your startup
CREATE A FINANCIAL MODEL
Create a long-term financial plan with required sheets
SALES AND MARKETING
Find the right audience for your business with the right market strategy
CREATING A VIABLE PRODUCT FOR MARKET
Creating your first product viable for the market and audience requirement
CREATE A PITCH FOR INVESTORS
Learn how to make a pitch deck using presentations for investors
IDEA PRESENTATION
Present your idea to angel investors to get funded


PerCuriam
WARNER-LAMBERT CO., LLC, et al., PETITIONERS v.KIMBERLY KENT et al.
Per Curiam.
The judgment is affirmed by an equally divided Court.
The Chief Justice took no part in the consideration or decision of this case.
PerCuriam
WARNER-LAMBERT CO., LLC, et al., PETITIONERS v.KIMBERLY KENT et al.
Per Curiam.
The judgment is affirmed by an equally divided Court.
The Chief Justice took no part in the consideration or decision of this case.
PerCuriam
WARNER-LAMBERT CO., LLC, et al., PETITIONERS v.KIMBERLY KENT et al.
Per Curiam.
The judgment is affirmed by an equally divided Court.
The Chief Justice took no part in the consideration or decision of this case.
PerCuriam
WARNER-LAMBERT CO., LLC, et al., PETITIONERS v.KIMBERLY KENT et al.
Per Curiam.
The judgment is affirmed by an equally divided Court.
The Chief Justice took no part in the consideration or decision of this case.
PerCuriam
WARNER-LAMBERT CO., LLC, et al., PETITIONERS v.KIMBERLY KENT et al.
Per Curiam.
The judgment is affirmed by an equally divided Court.
The Chief Justice took no part in the consideration or decision of this case.


US Dollar Index Technical Analysis: Keeps the recovery in place. Targets the 98.50 region.
by Pablo Piovano- The recovery in DXY remains well and sound above the 98.00 mark.
- Immediately above aligns the monthly peaks in the mid-98.00s.
The index is now flirting with the 55-day SMA in the 98.20/30 band, extending at the same time the positive streak for the fifth session.
Further upside impetus should now target monthly tops in the 98.50 region. A sustainable break of this hurdle should pave the way for a move to the 99.00 hurdle and potentially beyond.
In the meantime, as long as the 200-day SMA at 97.58 holds the downside, the constructive outlook on the buck remains unchanged.
Dollar Index Spot
| Overview | |
|---|---|
| Today last price | 98.3 |
| Today Daily Change | 14 |
| Today Daily Change % | 0.05 |
| Today daily open | 98.25 |
| Trends | |
|---|---|
| Daily SMA20 | 97.91 |
| Daily SMA50 | 98.24 |
| Daily SMA100 | 98.08 |
| Daily SMA200 | 97.59 |
| Levels | |
|---|---|
| Previous Daily High | 98.31 |
| Previous Daily Low | 97.82 |
| Previous Weekly High | 98.31 |
| Previous Weekly Low | 97.68 |
| Previous Monthly High | 99.67 |
| Previous Monthly Low | 97.15 |
| Daily Fibonacci 38.2% | 98.12 |
| Daily Fibonacci 61.8% | 98.01 |
| Daily Pivot Point S1 | 97.94 |
| Daily Pivot Point S2 | 97.64 |
| Daily Pivot Point S3 | 97.45 |
| Daily Pivot Point R1 | 98.43 |
| Daily Pivot Point R2 | 98.62 |
| Daily Pivot Point R3 | 98.92 |


Pledges galore as South Africans rally around KFC proposal couple
by Staff ReporterRomance was in the air this week as more than 300 companies and individuals offered to assist with planning the wedding of the highly publicised KFC proposal couple.
The wedding, which has been dubbed South Africa’s very own fast-food fairy tale by the BBC, has attracted top brands such as Audi, Total, Nedbank and Amstel as sponsors for Hector Kansi and Nonhlanhla Soldaat’s wedding, honeymoon and married life.
A video clip of Kansi proposing to his partner at a KFC in the Vaal went viral this week and led to South Africans working together to plan the perfect wedding.
In the recording, which was shared on Twitter by Kateka Malobola, Mkansi and Soldaat are about to dig into their KFC meals but before that can happen, he gets down on one knee and pops the question.
Once the video made waves online on Thursday, KFC tweeted about it, calling for the public to help find the couple and by Friday morning online sleuths had tracked them down.
It wasn’t long before South Africans started pledging their services for the couple’s wedding.
KFC was the first to pledge its support, followed by an offer from MTV Base to provide deejays for the reception. Celebrity chef Lesego Semenya committing to make a signature wedding cake, while travel site kulula.com pledged to gift the couple with a honeymoon in Cape Town.
Other generous people pledged to sponsor the bride’s dress, pay for the groom’s suit and donate rings of up to R45 000.
Musicians including Zakes Bantwini, Donald and DJ PH will be making sure that guests are entertained.
Standard Bank will be clearing the couple’s personal loans and rapper Cassper Nyovest has invited them to an all expenses paid trip to his upcoming annual FillUp event happening in Rustenburg.


Before Change
for (e_s, e_e, size) in zip(e_start, e_end, proba_hist):
candidates_proba = np.where((possible_mean_count >= e_s) *
(possible_mean_count < e_e),
size * np.ones_like(candidates),
candidates_proba)
proba_weight = np.multiply(proba_weight, candidates_proba)
print("Finished probability calculation")
After Change
for (e_s, e_e, size) in zip(e_start, e_end, proba_hist):
prob_selector = \
(possible_mean_count >= e_s) & (possible_mean_count < e_e)
candidates_proba[prob_selector.astype(np.bool)] = size
proba_weight = np.multiply(proba_weight, candidates_proba)
print("Finished probability calculation")
return np.divide(proba_weight, np.sum(proba_weight))


Computer Vision
Intro to Computer Vision
Computer vision is a field in Computing that tries to give computers and understanding of the world through vision, using sensors such as cameras or radar. Essentially, it tries to automate human vision. A lot of the time (such as in autonomous cars), machine learning is used to implement computer vision, so that the computer can find and make-decisions off of patters it sees. [2]
How it works
The first thing it will do (after gaining and pre-processing the data) is feature extraction. This will involve finding lines, corners and edges
The next step is segmentation. This is where specific images or parts of an image are chosen for further processing. Segmentation makes use of intermediate-level processing that identifies things such as boundaries, surfaces and volumes
The final step is high-level processing, where a small set of data is put forward for image recognition. This is the step where the car will decide if there is a person in front of it for example, or a car driving along side it.
Sensor fusion
Sensor fusion is how the data from all the sensors like the cameras, radar and LIDAR, are combined to build an understanding of the car’s environment. Some sensors are better than others at certain measurements (e.g. LIDAR and radar are better with distance than cameras), while some can work better in different weather conditions.  Using sensor fusion, we get fewer false positives or negatives.
Canvasing method
This is when the car looks over all of its sensors to tries to determine whether any of the sensors is giving false data. One way this is done is a voting protocol where if sensors are split on some data (e.g. if something is in front of the car) then it picks the sensors where the majority lies to be more reliable. [3]
RANSAC
Random Sample Consensus (RANSAC) aims to guess the parameters of a model by randomly sampling observed data that contains outliers, when outliers are given no influence on the estimates. [4]
Deep learning
The final approach we will discuss is fusing multiple inputs using a deep learning approach [5]. When doing RGB-D (Red, Green, Blue and Depth) object recognition, both RGB and D data are first processed separately by a pretrained Convolutional Neural Network (CNN), whose outputs are then concatenated and converged. This can be used for many things (as well as sensor fusion in cars), such as in this paper, where RGB-D data is used for detecting robotic grasps.
Deep reinforcement learning
This method uses deep neural network models as function approximators. The neural network represents a value function from which a policy can be derived. Q(s,a) is the expected discounted return (Q-value) of executing an action a in a given state s and executing policy π afterwards, an is defined as:
The reward r in each time step is discounted with a factor γ ∈ [0,1], which gives more weight to short-term rewards. The policy π (a|s) determines which action to take in each state. The optimal policy is found when following the optimal Q function Q∗ = maxπ E_π [Q(s,a)]. In Q-learning, Q∗ is typically found by iteratively taking the action with the highest Q-value, i.e. π (a|s) = argmaxaQ(s,a), until convergence
Sensor fusion combinations
Sensor fusion can be performed in complementary, competitive, or cooperative combinations
Complementary
A sensor combination is complementary when the sensors don't depend on each other and can be combined in order to give a more complete image of the environment. Combining this data is not very difficult since they can just be added to each other. The main disadvantage of this is that if one or more of the sensors is ineffective, it will lose part of its vision.
Competitive
Competitive sensor fusion combinations are used for fault-tolerant and robust systems. It has each sensor delivering independent measurements of the same target and can also provide robustness to a system by combining redundant information.
There are two possible competitive combinations:
- Fault tolerance - Requires an exact specification of the service and the failure modes of the system. In case of a fault, the system still has to provide its specified service.
- Competitive configurations - provide robustness to a system by delivering a degraded level of service in the presence of faults. While this is weaker than the fault tolerance, the respective algorithms perform better in terms of resource needs and work well with heterogeneous data sources
- An example would be the reduction of noise by combining two overlaying camera images
Cooperative
This combines non-redundant data from all the sensors. The result is often too sensitive to inaccuracies present in individual sensors, which means cooperative sensor fusion is probably the most difficult to design. So cooperative sensor fusion has worse accuracy and reliability than competitive sensors.
An example of a cooperative sensor configuration is when a three-dimensional image is made by combining two-dimensional images from two cameras at slightly different viewpoints
SLAM
The next part of the process is Simultaneous Localisation and Mapping (SLAM), which you can read about here
Sources- [1] Self-driving car picture
- [2] Wikipedia - Computer Vision
- [3] Peter Els - AutomotiveIQ - "Intelligent sensor fusion for smart cars"
- [4] Wikipedia - Random sample consensus
- [5] Steven Bohez, Tim Verbelen, Elias De Coninck, Bert Vankeirsbilck, Pieter Simoens and Bart Dhoedt, "Sensor Fusion for Robot Control through Deep Reinforcement Learning", 13 March 2017