Last year we were at Washington DC viewing the museums and
monuments during the famous Annapolis boat showboat but this
year we were in Annapolis MD for it. There are a couple
boat shows that are really "bucket list" shows and this one is
one of those. They break the boat show into two weeks, the
first is for sail boats and the second week is for power boats.
We only stayed for the sailboats.
Since the show is very popular you need to get hotel
reservations, marina reservations or find your anchor spot early
or you might be sorry. We arrived a week early and
anchored in Back Creek with lots of room and space around us.
As the boat show came closer the creek filled up and by the
pictures you can see many more boats came in.
There were two new families on Manta catamarans out sailing this
year that were at the boat show, Marce/Jack on Escape
Velocity and Craig/Wendy/Maggie/Kate/Olivia on Anything
Goes. Craig had a birthday and at his party we also
met Wil/Jenny/Justine/Colin on Full Monty, a
47 foot catamaran. For once Derek had lots of kids to play
with at a cruiser get together. Scott and Tina off
Sangaris, a Manta 42 that we met in the Bahamas, live in
Annapolis and they also attended. It was good to catch up
with Scott and Tina on their adventures over the summer and
plans for the upcoming winter.
Derek was thrilled to meet Colin off of Full Monty, as
he is a Minecraft fan as well. (Minecraft is a computer game
that Derek spends his free time playing). Colin came over
to the boat after school two days in a row, and Derek and him
played Minecraft for a couple of hours each day.
We only had a few things to look at in the boat show but some
how we spent the entire day there, Derek wished it had been a
bit shorter. While there we viewed some new catamarans,
not to buy but to get new ideas on. We did stop by the
Manson Supreme Anchor booth and talk to the rep about how
pleased we are with the anchor and he gave us three watch caps.
The caps have come in handy with the recent cooler weather.
We also stopped by the Parasailor booth, a new design of
spinnaker that has a hangglider like wing built into the sail.
Derek got a really nice shirt from them. All in all we
could have spent another day walking the show but we had
purchased what we needed so it was time to head south.
Friday night there was a Manta get together at a local
restaurant. We had seven different Manta owners in town
and three boats were currently cruising. The Manta owners
share a website where issues and questions can be talked about
with other who have the same questions. It was good to put
faces to some of the names and the dinner was rather good as
well.
On Saturday we hoisted anchor and headed south, we did not make
it far because the winds and waves were beating us up so after
only a couple of hours we pulled into a protected anchorage and
spent the night. The next day we left again and made it
down past the Potomac river. On Monday we sailed down to
Deltaville and stopped to see our friends Bob and Anne off
Baloo.
Update 10/08/12; Annapolis boat show
Craig's birthday party |
Derek and boating kids |
anchorage pre boat show |
anchorage during boat show |
Manson anchor |
parasailor |
manta dinner |
|
| |
|


{% block title %}
{{ account.realname }}
{% endblock %}
{% include 'lastfm/includes/page_navigation.html' with request=request url_name=url_name counts=counts account=account only %}
{% include 'lastfm/includes/annual_scrobble_counts.html' with account=account only %}


Early detection by smoke alarm helped firefighters stop fire in downtown business
Bags of oily rags were smoldering
by Maija InveissMADISON, Wis. - Firefighters stopped a fire from breaking out in a downtown business at 4:30 a.m. Wednesday morning, in part because of early detection by a smoke alarm.
According to a release, a resident in the 300 block of North Randall Street woke up at 4:30 a.m. to the sound of an alarm and found the common area "very smoky." The resident called 911.
Medic 4 and Engine Co. 1 arrived to find a haze of smoke in the building. Ladder Co. 1 accessed a downstairs business, finding two bags of oily rags. One of the bags was smoldering on the floor.
Firefighters cooled the bag with a water can and then took the rags outside, the release said. Crews ventilated the building to clear the smoke and tenants were allowed to return inside, according to the release.
The release said the smoke detector's early warning prevented the smoldering rags from igniting a fire, which could have caused significant damage and put lives at risk.
The release reminds people to dispose of oily rags properly so they don't start a fire. It says that, if you have oily rags, never leave them in a pile, and dispose of dried rags in a metal container.


--- layout: page title: Reports ---
This page contains a list of links to examples of my work. Some of the reports are from University Work, some are from Personal Projects. Depending upon how much time I had to complete them they will be of varying quality; I hope you find them useful and informative. If you have any questions please get in touch!
{% for entry in site.data.reports %}


Rosegate Morphology
Our intent in this section is to explore the gradation between Rose Spring and Eastgate points using geometric morphometric (GM) landmark analysis. We used published illustrations and photographs from seven sites (see Table 3), as well as photographs from Wolf Village. We included points typed as Rosegate, Eastgate, Parowan Basal-notched (hereafter Parowan), and unclassified side-notched points. The inclusion of the Parowan and side-notched points is used as a control to test how well this analysis can discriminate between types. Parowan points are most commonly found in the southwestern Fremont region and bordering areas. They are morphologically similar to Rosegate points but with basal notches instead of corner notches and a flat-base preform instead of a rounded-base preform (see Holmer and Weder 1980). In GM, landmarks are specific locations on each object that correspond to features on other objects. Projectile points have some features that correspond between different types (such as tips and corners), but here we use semi-landmarks. Semi-landmarks are evenly spaced points along an edge or other feature and are often used on object outlines (Bookstein 1997). The semi-landmark coordinates must be aligned prior to further analysis. Generalized Procrustes analysis (GPA), developed by Gower (1975) and later adapted for GM by Rohlf and Slice (1990), is a way to rotate, scale, and align a series of landmarks. GPA-based analysis is one of the most commonly used GM methods in archaeology (e.g., Buchanan and Collard 2010; Cardillo 2010; Lycett et al. 2010; MacLeod 2018; Okumura and Araujo 2019; Selden et al. 2018; Shott and Trail 2010; Smith et al. 2015; Thulman 2019). The aligned coordinates can be used in standard multivariate statistical analyses.
| Origin | Number of Points | Citation |
|---|---|---|
| Baker Village | 5 | Wilde and Soper 1999:Figure 46 |
| Various | 8 | Holmer and Weder 1980 |
| Hunchback Shelter | 79 | Reed et al. 2005:Figure 3.31-3.38 |
| Various | 52 | Justice 2002:Figure 28 |
| Parowan Valley | 17 | Woods 2009:Figure 3.1 |
| Radford Roost | 2 | Talbot et al. 1999:Figure 1.37 |
| South Temple | 9 | Talbot et al. 2004:Figure 6.17 |
| Wolf Village | 21 | Unpublished |
A potential problem for projectile point analyses and typologies is the modification of a point throughout its use-life. The term retouching describes modifications to a stone tool after its initial shaping (Whittaker 1994:19). Retouching is generally done to increase the sharpness of the blade, although these modifications can sometimes affect the typology of the point (e.g., Bamforth 1991; Flenniken and Raymond 1986; Gardner and Verrey 1979; Larick 1985; Thomas 1986). However, experiments indicate this is rarely a problem for small arrowpoints. Loendorf and colleagues (see also Cheshier and Kelly 2006; 2019) conducted an experimental study of arrowpoints, comparable to Rosegate points, and found that the breakage patterns and decline in performance for reworked points make these points unlikely to be affected by reworking. Notably, attempting to rework points resulted in unusual morphologies rarely or never found in the archaeological record. This perhaps justifies the analysis of the entire point outline, but we elected to focus our analysis on the base, as base shape is usually the primary discriminant between types in the Great Basin (Holmer 1986; Holmer and Weder 1980; Thomas 1981) and does not seem likely to be affected by reworking. This has the added bonus of increasing the sample size as many points are damaged at the tip or along one side and must be discarded in an analysis considering the entire outline.
Landmarks are usually added manually, but this means landmarks can be subjective and subject to human error. Instead, we automated the process to create semi-landmarks using the R statistical language (R Core Team 2020) and the Momocs package (Bonhomme et al. 2014). The R script used to process the images is publicly available (see data availability statement), but we briefly describe the process here. Each image is converted to a matrix of points representing the outline of the projectile point. These matrices are aligned and centered and then the upper half of the point and the left half of the point are removed (see Figure 9). This leaves a corner of the projectile point to be used for the landmarks. This method could be refined by separating the blade and base components, but we found this shortcut to work effectively. Only a corner was used in the analysis instead of the entire base in order to eliminate biases from asymmetric points and to use points where one side of the base was damaged. Furthermore, the inclusion of part of the blade margin provides additional shape variation for analysis and is unlikely to cause problems given the general lack of extensive resharpening in these points. The remaining coordinates for the projectile point corner are then sampled so that an equal number of coordinates remain for all projectile points, which is required for GPA. We chose 35 as this is the approximate average number of points remaining after the removal of the other points. GPA and principal components analysis were then applied to align and transform the coordinates into principal component vectors.
Figure 10 shows the first two principal components, as well as the morphospace, which demonstrates the relationship between the principal components scores and the shape of the outlines. Side notch points and Parowan points are mostly separated from Rose Spring and Eastgate, although one point originally classified as Parowan appears to be misclassified. Rose Spring and Eastgate are, however, mostly overlapping.
Using linear discriminant analysis (LDA) on the PCA results allows us to test how accurately the original typologies can be reproduced using this analysis. While true training and validation sets were not used in this small experiment, this provides a sense of how a GM approach compares to traditional methods. Table 4 shows the results of the predicted types using LDA and the original classification. The accuracy overall was 84% (n = 193). Each type had over 90% accuracy, except Eastgate which was 62%. The combination of Rose Spring and Eastgate into a Rosegate category would eliminate much of the error and increase the accuracy rate to 93%. The question remains, can Rose Spring and Eastgate points be reasonably separated, or should they be considered one type?
| Actual Type | Eastgate | Parowan | Rose Spring | side notch | accuracy |
|---|---|---|---|---|---|
| Eastgate | 28 | 1 | 16 | 0 | 62% |
| Parowan | 1 | 17 | 1 | 0 | 89% |
| Rose Spring | 4 | 5 | 108 | 2 | 91% |
| side notch | 0 | 0 | 1 | 9 | 90% |
Rose Spring and Eastgate points appear to lie along a continuous spectrum of morphological variability, but difficulty separating them may also be due to analyst error or to definitional error. The PCA plot does little to separate these two types, although the LDA analysis does a better job. Uniform manifold application and projection (UMAP) is a relatively recent algorithm for reducing dimensionality (McInnes et al. 2020). We use the algorithm as implemented through the “umap” package in R (Konopka 2020). The PCA results from the GPA analysis were used as the input for the UMAP algorithm and a K-means cluster analysis was used to create two groups. Figure 11 shows the results of this analysis. The K-means clearly only used one axis to separate the types. The group 2 points on the right-hand side would better fit group 1, but overall, this analysis produced a u-shaped distribution with some separation between the two groups. The original types, however, are not well separated.
This analysis suggests that Rose Spring and Eastgate cannot clearly be distinguished. Certain specimens are more clearly Eastgate or Rose Spring using the current definitions, but many points cannot be discriminated with reasonable certainty. Typologies are something we construct as necessary to make interpreting variation easier, but the difficulty of separating these types arguably supports the use of the combined Rosegate type, unless a particular research question requires a finer-grained distinction. If the types were to be redefined using a GM approach, then we would recommend a larger sample size and a more refined clustering approach.


Settings
Contact Details
Mobile phone Settings
Change Password
Manage my account
About Mozy app
Frequently Asked Questions
Phone Number Settings
Your phone number
Enter your new phone number
×
SAVE PHONE


ADLightField¶
areaDetector LightField driver
| author: | Mark Rivers, University of Chicago |
|---|
Contents
Introduction¶
This is an areaDetector driver for recent Princeton Instruments detectors including the ProEM, PIXIS, PI-MAX3, PI-MAX4, PyLoN, and Quad-RO. It also supports the Acton Series spectrographs.
The interface to the detector is via the Microsoft Common Language Runtime (CLR) interface to the LightField program that Princeton Instruments sells. The areaDetector driver effectively “drives” LightField through the CLR interface, performing most of the same operations that can be performed using the LightField GUI. The advantage of this communication mechanism is that the user can continue to use LightField for viewing images and for configuration operations. LightField is automatically started when the areaDetector software is started.
Because EPICS and the LightField GUI can control many of the same parameters the user must be aware of the interactions between the two control systems. The basic rule is that the value of a parameter will be determined by whichever control system last wrote to that parameter. The LightField widget will display the current value of a parameter no matter how it was last changed. EPICS will correctly display the current value of the parameter in the “readback” record, which typically ends in “_RBV”, no matter how the value was last changed. However the EPICS output record does not currently update if the value is changed in LightField. This may change in a future version of asyn device support.
This driver inherits from ADDriver. It implements many of the parameters asynNDArrayDriver.h and in ADArrayDriver.h. It also implements a number of parameters that are specific to the LightField application.The LightField class documentation describes this class in detail.
Implementation of standard driver parameters¶
The following table describes how the LightField driver implements some of the standard driver parameters. Note that there are 4 possible levels of nested acquisition looping when using the LightField driver. From the innermost to outermost loop these are as follows:
- LFNumAccumulations
$(P)$(R)NumAccumularions
. This controls the number of accumulations per image. Accumulations are acquired in hardware on the detector before it is read out. - ADNumExposures
$(P)$(R)NumExposures
. This controls the number of images that are summed together by LightField into a single image. - ADNumImages
$(P)$(R)NumImages
. This controls the number of images per acquisition. This is also called AcquisitionFramesToStore in LightField’s terminology. These images will all be acquired into a single 3-D array, and saved to a single SPE file in LightField. - LFNumAcquisitions
$(P)$(R)NumAcquisitions
. This controls the number of times that the driver will repeat an acquisition sequence. This is has no equivalent in LightField, it is handled entirely by the areaDetector driver. It can be used to acquire multiple data sets, where each is controlled by the above parameters. NOTE: NumAcquisitions is not yet implemented, but is planned in a future release.
| Implementation of Parameters in asynNDArrayDriver.h and ADDriver.h, and EPICS Record Definitions in ADBase.template and NDFile.template | ||
|---|---|---|
| Parameter index variable | EPICS record name | Description |
| ADImageMode | $(P)$(R)ImageMode | The driver redefines the choices for the ADImageMode parameter (record $(P)$(R)ImageMode) from ADDriver.h. The choices for the LightField are:
|
| ADNumExposures | $(P)$(R)NumExposures | Controls the number of exposures that LightField will sum into a single image. |
| ADNumImages | $(P)$(R)NumImages | Controls the number of images to acquire into a single 3-D data set. |
| ADGain | $(P)$(R)Gain | The precision of the $(P)$(R)Gain record is changed to 0 because the gain in LightField is an integer. Allowed values are detector dependent, but 1 and 2 are typically supported. |
LightField specific parameters¶
The LightField driver implements the following parameters in addition to those in asynNDArrayDriver.h and ADDriver.h.
| Parameter Definitions in LightField.cpp and EPICS Record Definitions in LightField.template | ||
|---|---|---|
| Description | EPICS record name | EPICS record type |
| Acquisition parameters | ||
| The number of on-chip accumulations to perform per image. | $(P)$(R)NumAccumulations, $(P)$(R)NumAccumulations_RBV | longout, longin |
The number of acquisitions to perform when acquisition is started. This controls the number of iterations in the outermost acquisition loop explained above. NOTE: This is not yet implemented, it is planned for a future release. |
$(P)$(R)NumAcquisitions, $(P)$(R)NumAcquisitions_RBV | longout, longin |
| The number of acquisitions performed so far. | $(P)$(R)NumAcquisitionsCounter_RBV | longin |
| The camera gain. This parameter is used instead of the base class ADGain parameter so that it can be displayed as a menu as LightField does. | $(P)$(R)LFGain, $(P)$(R)LFGain_RBV | mbbo, mbbi |
The shutter operating mode for shutters controlled by LightField. Allowed values are:
|
$(P)$(R)LFShutterMode, $(P)$(R)LFShutterMode_RBV | mbbo, mbbi |
| Experiment parameters | ||
| Selects the LightField experiment, which is a set of experimental conditions including the selected camera, etc. The record choices are constructed at run-time based on the experiment files currently available. | $(P)$(R)LFExperimentName, $(P)$(R)LFExperimentName_RBV | mbbo, mbbi |
| Updates the choices in the LFExperimentName records. This is only needed if a new experiment is created after the EPICS IOC is started. | $(P)$(R)LFUpdateExperiments | bo |
| Spectrometer parameters | ||
| Selects the spectrometer grating. The record choices are constructed at run-time based on the gratings actually available. | $(P)$(R)LFGrating, $(P)$(R)LFGrating_RBV | mbbo, mbbi |
| Selects the center wavelength of the spectrometer. | $(P)$(R)LFGratingWL, $(P)$(R)LFGratingWL_RBV | ao, ai |
| Selects the starting wavelength of the spectrometer for Step And Glue. | $(P)$(R)LFSAGStartingWL, $(P)$(R)LFSAGStartingWL_RBV | ao, ai |
| Selects the ending wavelength of the spectrometer for Step And Glue. | $(P)$(R)LFSAGEndingWL, $(P)$(R)LFSAGEndingWL_RBV | ao, ai |
| Enables and disables Step and Glue. | $(P)$(R)LFSAGEnable, $(P)$(R)LFSAGEnable_RBV | bo, bi |
| Selects the entrance width of the side port on the spectrometer in microns. | $(P)$(R)LFEntranceWidth, $(P)$(R)LFEntranceWidth_RBV | longout, longin |
Selects the entrance port of the spectrometer. Choices are:
|
$(P)$(R)LFEntrancePort, $(P)$(R)LFEntrancePort_RBV | mbbo, mbbi |
Selects the exit port of the spectrometer. Choices are:
|
$(P)$(R)LFExitPort, $(P)$(R)LFExitPort_RBV | mbbo, mbbi |
| File name parameters. These are in addition to the normal parameters from NDFile.template. | ||
| The actual file path for saving data. | $(P)$(R)LFFilePath_RBV | waveform |
| The actual file name for saving data. | $(P)$(R)LFFileName_RBV | waveform |
| The file path to use for saving background data. | $(P)$(R)LFBackgroundPath, $(P)$(R)LFBackgroundPath_RBV | waveform, waveform |
| Flag to indicate if the file path to use for saving background data exists. If it does not exist it will be created if the $(P)$(R)CreateDirectory PV is set appropriately. | $(P)$(R)LFBackgroundPathExists_RBV | bi |
| The file name to use for saving background data. | $(P)$(R)LFBackgroundFile, $(P)$(R)LFBackgroundFile_RBV | waveform, waveform |
| The actual full file name for saving background data. | $(P)$(R)LFBackgroundFullFile_RBV | waveform |
| Enable background correction. | $(P)$(R)LFBackgroundEnable, $(P)$(R)LFBackgroundEnable_RBV | bo, bi |
| Image intensifier and timing parameters. | ||
| Enable image intensifier. | $(P)$(R)LFIntensifierEnable, $(P)$(R)LFIntensifierEnable_RBV | bo, bi |
| Image intensifier gain. | $(P)$(R)LFIntensifierGain, $(P)$(R)LFIntensifierGain_RBV | ao, ai |
Image intensifier gating mode. Choices are:
|
$(P)$(R)LFGatingMode, $(P)$(R)LFGatingMode_RBV | mbbo, mbbi |
| Selects the intensifier trigger frequency. | $(P)$(R)LFTriggerFrequency, $(P)$(R)LFTriggerFrequency_RBV | ao, ai |
| Enable sync master. | $(P)$(R)LFSyncMasterEnable, $(P)$(R)LFSyncMasterEnable_RBV | bo, bi |
| Selects the sync master 2 delay. | $(P)$(R)LFSyncMaster2Delay, $(P)$(R)LFSyncMaster2Delay_RBV | ao, ai |
| Selects the repetitive gate width. | $(P)$(R)LFRepGateWidth, $(P)$(R)LFRepGateWidth_RBV | ao, ai |
| Selects the repetitive gate delay. | $(P)$(R)LFRepGateDelay, $(P)$(R)LFRepGateDelay_RBV | ao, ai |
| Selects the sequential start gate width. | $(P)$(R)LFSeqStartGateWidth, $(P)$(R)LFSeqStartGateWidth_RBV | ao, ai |
| Selects the sequential start gate delay. | $(P)$(R)LFSeqStartGateDelay, $(P)$(R)LFSeqStartGateDelay_RBV | ao, ai |
| Selects the sequential end gate width. | $(P)$(R)LFSeqEndGateWidth, $(P)$(R)LFSeqEndGateWidth_RBV | ao, ai |
| Selects the sequential end gate delay. | $(P)$(R)LFSeqEndGateDelay, $(P)$(R)LFSeqEndGateDelay_RBV | ao, ai |
| Selects the auxiliary width. | $(P)$(R)LFAuxWidth, $(P)$(R)LFAuxWidth_RBV | ao, ai |
| Selects the auxiliary delay. | $(P)$(R)LFAuxDelay, $(P)$(R)LFAuxDelay_RBV | ao, ai |
| Miscellaneous parameters. | ||
| Enable background correction. | $(P)$(R)LFBackgroundEnable, $(P)$(R)LFBackgroundEnable_RBV | bo, bi |
| Flag indicating if LighField is ready to collect data. | $(P)$(R)ReadyToRun | bi |
Configuration¶
The LightField driver is created with the LightFieldConfig command, either from C/C++ or from the EPICS IOC shell.
int LightFieldConfig(const char *portName, const char *experimentName,
int maxBuffers, size_t maxMemory,
int priority, int stackSize)
For details on the meaning of the parameters to this function refer to the detailed documentation on the LightFieldConfig function in the LightField.cpp documentation and in the documentation for the constructor for the LightField class.
Example st.cmd startup file¶
There an example IOC boot directory and startup script provided with areaDetector: Example st.cmd Startup File.
MEDM screens¶
The following show the MEDM screens that are used to control the LightField detector. Note that the general purpose screen ADBase.adl can be used, but it exposes a few controls that are not applicable to the LightField, and lacks some fields that are important for the LightField.
LightField.adl¶
LightField.adl is the main screen used to control the LightField driver.
LightFieldFile.adl¶
LightFieldFile.adl is the screen used to control LighField file I/O.
LighField program from Priceton Instruments¶
LighField is the program that the LightField driver is controlling via Microsoft Common Language Runtime.
Restrictions¶
The following are some current restrictions of the LightField driver:
- If LightField encounters an error it will crash the IOC. The driver establishes an exception handler, but this does not seem to work correctly with the LightField CLR interface.