- API
GPM, DPR, GMI Level 3 Combined Precipitation V03
nasa-test-0.demo.socrata.com | Last Updated 2015-07-20T05:03:54.000ZThere are uncertainties in the interpretation of data from any one of the instruments (KuPR, KaPR, and GMI). By using data from multiple instruments, further constraints on the solution of precipitation structure improve the final product.The purpose of 3CMB is to give a daily and monthly accumulation of the 2BCMB precipitation product. The 3CMB product is a daily and monthly accumulation of the 2BCMB orbital combined product at two grid sizes, 5 x 5 degrees (G1) and 0.25 x 0.25 degrees (G2). Grid G1 contains the following physical measurements of general interest, among others. Grid G2 contains the same groups, but it is on the ltH x lnH grid and does not have the surface type (st) dimension or the histograms (see dimension definitions below). Below, conditional products represent means based upon precipitating areas only; unconditional products represent means for raining and non-raining areas combined. Probabilities represent the number of raining observations divided by the total number of raining and non-raining observations. precipTotRate (Group in G1)- Conditional mean rate for all precipitation phases (ice, liquid, mixed-phase). * count (4-byte integer, array size: ltL x lnL x ns x hgt x rt x st): Count. * mean (4-byte float, array size: ltL x lnL x ns x hgt x rt x st): Mean, mm/h. * stdev (4-byte float, array size: ltL x lnL x ns x hgt x rt x st): Standard deviation for the monthly product. Mean of squares for the daily product, mm/h. * hist (4-byte integer, array size: ltL x lnL x ns x hgt x rt x st x bin): Histogram. precipLiqRate (Group in G1) - Conditional mean rate for liquid precipitation. * count (4-byte integer, array size: ltL x lnL x ns x hgt x rt x st): Count. * mean (4-byte float, array size: ltL x lnL x ns x hgt x rt x st): Mean, mm/h. * stdev (4-byte float, array size: ltL x lnL x ns x hgt x rt x st): Standard deviation for the monthly product. Mean of squares for the daily product, mm/h. * hist (4-byte integer, array size: ltL x lnL x ns x hgt x rt x st x bin): Histogram. precipTotWaterContent (Group in G1) - Conditional mean water content for all precipitation phases. * count (4-byte integer, array size: ltL x lnL x ns x hgt x rt x st): Count. * mean (4-byte float, array size: ltL x lnL x ns x hgt x rt x st): Mean, g/m3. * stdev (4-byte float, array size: ltL x lnL x ns x hgt x rt x st): Standard deviation for the monthly product. Mean of squares for the daily product, g/m3. * hist (4-byte integer, array size: ltL x lnL x ns x hgt x rt x st x bin): Histogram. precipLiqWaterContent (Group in G1) - Conditional mean liquid water content. * count (4-byte integer, array size: ltL x lnL x ns x hgt x rt x st): Count. * mean (4-byte float, array size: ltL x lnL x ns x hgt x rt x st): Mean, g/m3. * stdev (4-byte float, array size: ltL x lnL x ns x hgt x rt x st): Standard deviation for the monthly product. Mean of squares for the daily product, g/m3. * hist (4-byte integer, array size: ltL x lnL x ns x hgt x rt x st x bin): Histogram. precipTotDm (Group in G1) - Conditional mass-weighted mean particle diameter. * count (4-byte integer, array size: ltL x lnL x ns x hgt x rt x st): Count. * mean (4-byte float, array size: ltL x lnL x ns x hgt x rt x st): Mean, mm. * stdev (4-byte float, array size: ltL x lnL x ns x hgt x rt x st): Standard deviation for the monthly product. Mean of squares for the daily product, mm. * hist (4-byte integer, array size: ltL x lnL x ns x hgt x rt x st x bin): Histogram. precipTotRateDiurnal (Group in G1) - Conditional mean total surface precipitation rate indexed by local time. * count (4-byte integer, array size: ltL x lnL x ns x st x tim): Count. * mean (4-byte float, array size: ltL x lnL x ns x st x tim): Mean, mm/h. * stdev (4-byte float, array size: ltL x lnL x ns x st x tim): Standard deviation for the monthly product. Mean of squares for the daily product, mm/h. surfPrecipTotRateDiurnalAllObs (4-byte integer, array size: ltL x lnL x ns x st x tim): Number of total observa...
- API
Surface Turbulent Fluxes, 1x1 deg Daily Grid, Set1 V2c
nasa-test-0.demo.socrata.com | Last Updated 2015-07-19T08:49:10.000ZThese data are the Goddard Satellite-based Surface Turbulent Fluxes Version-2c (GSSTF2c) Dataset recently produced through a MEaSUREs funded project led by Dr. Chung-Lin Shie (UMBC/GEST, NASA/GSFC), converted to HDF-EOS5 format. The stewardship of this HDF-EOS5 dataset is part of the MEaSUREs project, http://earthdata.nasa.gov/our-community/community-data-system-programs/measures-projects/surface-turbulent-fluxes-esdr http://earthdata.nasa.gov/our-community/community-data-system-programs/measures-projects GSSTF version 2b (Shie et al. 2010, Shie et al. 2009) generally agreed better with available ship measurements obtained from several field experiments in 1999 than GSSTF2 (Chou et al. 2003) did in all three flux components, i.e., latent heat flux [LHF], sensible heat flux [SHF], and wind stress [WST] (Shie 2010a,b). GSSTF2b was also found favorable, particularly for LHF and SHF, in an intercomparison study that accessed eleven products of ocean surface turbulent fluxes, in which GSSTF2 and GSSTF2b were also included (Brunke et al. 2011). However, a temporal trend appeared in the globally averaged LHF of GSSTF2b, particularly post year 2000. Shie (2010a,b) attributed the LHF trend to the trends originally found in the globally averaged SSM/I Tb's, i.e., Tb(19v), Tb(19h), Tb(22v) and Tb(37v), which were used to retrieve the GSSTF2b bottom-layer (the lowest atmospheric 500 meter layer) precipitable water [WB], then the surface specific humidity [Qa], and subsequently LHF. The SSM/I Tb's trends were recently found mainly due to the variations/trends of Earth incidence angle (EIA) in the SSM/I satellites (Hilburn and Shie 2011a,b). They have further developed an algorithm properly resolving the EIA problem and successfully reproducing the corrected Tb's by genuinely removing the "artifactitious" trends. An upgraded production of GSSTF2c (Shie et al. 2011) using the corrected Tb's has been completed very recently. GSSTF2c shows a significant improvement in the resultant WB, and subsequently the retrieved LHF - the temporal trends of WB and LHF are greatly reduced after the proper adjustments/treatments in the SSM/I Tb's (Shie and Hilburn 2011). In closing, we believe that the insightful "Rice Cooker Theory" by Shie (2010a,b), i.e., "To produce a good and trustworthy 'output product' (delicious 'cooked rice') depends not only on a well-functioned 'model/algorithm' ('rice cooker'), but also on a genuine and reliable 'input data' ('raw rice') with good quality" should help us better comprehend the impact of the improved Tb on the subsequently retrieved LHF of GSSTF2c. This is the Daily (24-hour) product; data are projected to equidistant Grid that covers the globe at 1x1 degree cell size, resulting in data arrays of 360x180 size. A finer resolution, 0.25 deg, of this product has been released as Version 3. The GSSTF, Version 2c, daily fluxes have first been produced for each individual available SSM/I satellite tapes (e.g., F08, F10, F11, F13, F14 and F15). Then, the Combined daily fluxes are produced by averaging (equally weighted) over available flux data/files from various satellites. These Combined daily flux data are considered as the "final" GSSTF, Version 2c, and are stored in this HDF-EOS5 collection. There are only one set of GSSTF, Version 2c, Combined data, "Set1" It contains 9 variables: "E" 'latent heat flux' (W/m**2), "STu" 'zonal wind stress' (N/m**2), "STv" 'meridional wind stress' (N/m**2), "H" 'sensible heat flux' (W/m**2), "Qair" 'surface air (~10-m) specific humidity' (g/kg), "WB" 'lowest 500-m precipitable water' (g/cm**2), "U" '10-m wind speed' (m/s), "DQ" 'sea-air humidity difference' (g/kg) "Tot_Precip_Water" 'total precipitable water' (g/cm**2) The double-quoted labels are the short names of the data fields in the HDF-EOS5 files. The "individual" daily flux data files, produced for each individual satellite, are also available in HDF-EOS5, although from differe...
- API
Procedure Execution and Projection System
nasa-test-0.demo.socrata.com | Last Updated 2015-07-20T05:15:38.000ZThere is a persistent pressure upon NASA crew members to achieve very high productivity during their missions. Significant challenges exist to maintaining manageable workload while the crew is performing their many and varied tasks allotted for each day while ensuring the crew maintain situation awareness. NASA crew members deal with a large amount of very high technology equipment and perform experiments and procedures that can be extremely long and complex. The solution will require the development of automated management technologies that will operate synergistically with the crew, automating tasks of varying complexity in a dynamic, flexible manner with representations of automation state that the crew is familiar and comfortable with. In this proposal, Cybernet proposes to leverage crew members' capabilities with the design of a distributed Procedure Execution and Projection (PEP) system that focuses on supporting automation of complex procedures while ensuring crew situational awareness and anticipating future problems. Our team will leverage the recent work on the Procedure Representation Language (PRL) and the flexible, distributed and hierarchical capabilities of holonic systems. PRL is an XML encoding of the vehicle/habitat procedures in a form that both crew and automation can use, and the PEP systems' intelligent holonic modules will support crew with a range of capabilities, including automation of procedures, projection of procedures to look for problems and determine courses of action to prevent or mitigate the problems, and make sure that the crew maintain situational awareness of the procedural state. The objectives of the Phase I project are to establish critical requirements for NASA vehicle and habitat crew automation and to design and implement a prototype of the PEP system to demonstrate approach viability.
- API
Auditory Presentation of H/OZ Critical Flight Data Project
nasa-test-0.demo.socrata.com | Last Updated 2015-07-20T05:08:03.000ZAutomation of a flight control system to perform functions normally attributed to humans is often not robust and limited to specific operating conditions and types of operation and a small set of fixed behaviors (i.e. modes). eSky has shown that metrics such as the time delay between a required control input from the crew and the actual input is sensitive to crew functional degradation through external distraction. We are currently developing strategies for using such crew state metrics to modulate the level of automation support provided to the flight crew. Dynamic reallocation of function between crew and automation can reduce the cognitive workload on the crew, enhance their ability to supervise the automation and help them intervene in the event of any failure or operation outside the desired operating conditions. eSky is exploring function reallocation in a collaborative flight control system (HFCS) design pioneered at NASA Langley. HFCS combines precise flight control automation with rudimentary intelligence that the flight crew can guide using relatively simple mechanisms. HFCS automation manages short-term control tasks (e.g. path following) while the crew is required to direct every significant trajectory change using flight controls rather than an FMS interface to keep them engaged in conduct of the flight. The automation communicates intentions to the pilot through visual and haptic (tactile) feedback; the crew communicates intentions to the automation through conventional controls. The HFCS user interface is primarily visual and tactile with limited auditory elements, mainly limited to a few alerts and warnings. eSky proposes to establish the auditory channel as a key element in providing flight dynamic information and cueing of required crew in puts in addition to envelope protection warnings. These new interface elements will be integrated into eSky's evolving strategies for functionality reallocation of between automation and crew.
- API
Approximate Cartesian Control for Robotic Tool Usage with Graceful Degradation Project
nasa-test-0.demo.socrata.com | Last Updated 2015-07-20T05:31:39.000ZMany of NASA's exploration scenarios include important roles for autonomous or partially autonomous robots. It is desirable for them to utilize human tools when possible, rather than needing to build custom tools for each robot. Control of robotic manipulators for tool usage generally requires a very precise Cartesian-space trajectory of the tool tip (e.g., moving a marker along the surface of a whiteboard or rotating a screwdriver about an axis). Well-known techniques exist for manipulator control in Cartesian space, most of which necessitate solving a series of Inverse Kinematics (IK) problems. Closed-form IK solvers work well for 7-degree-of-freedom (DOF) arms with rigid tool attachments, but cannot handle non-rigid tools that slip in the robot's hands. Numerical IK approaches are more generic and can handle non-rigid links to tools, but can be slow to converge. More importantly, if any joints fail or become limited in their range of motion, the robot arm essentially becomes 6-DOF or lower. IK solvers often fail in these lower DOF spaces because the configuration space becomes non-continuous and full of "holes". As a result, a 7-DOF robotic arm in space might be rendered largely useless if a single joint fails or even loses mobility until it can be serviced. TRACLabs proposes to investigate an alternative approach to traditional Cartesian control approaches, which rely on complex IK solvers that go from Cartesian space backwards to joint space. We propose to leverage cheap memory and modern processing speeds to instead perform simple computations that go from joint space forwards to Cartesian space. Such techniques should overcome common changes to a manipulation chain caused by tool slippage or the grasping of a new tool and to overcome uncommon changes to a chain caused by joint failures, reduced joint mobility, changes in joint geometry or range of motion, or added joints.
- API
TRMM Microwave Imager (TMI) Gridded Oceanic Rainfall Product (TRMM Product 3A11) V7
nasa-test-0.demo.socrata.com | Last Updated 2015-07-20T04:52:56.000ZThe Tropical Rainfall Measuring Mission (TRMM) is a joint U.S.-Japan satellite mission to monitor tropical and subtropical precipitation and to estimate its associated latent heating. TRMM was successfully launched on November 27, at 4:27 PM (EST) from the Tanegashima Space Center in Japan. The TRMM Microwave Imager (TMI) is a nine-channel passive microwave radiometer, which builds on the heritage of the Special Sensor Microwave/Imager (SSM/I) instrument flown aboard the Defense Meteorological Satellite Program (DMSP) platforms. Microwave radiation is emitted by the Earth's surface and by water droplets within clouds. However, when layers of large ice particles are present in upper cloud regions - a condition highly correlated with heavy rainfall - microwave radiation tends to scatter at frequencies above 19 GHz. The TMI detects radiation at five frequencies chosen to discriminate among these processes, thus revealing the likelihood of rainfall. The key to accurate retrieval of rainfall rates by this method is the deduction of cloud precipitation consistent with the radiation measurement at each frequency. The TMI frequencies are 10.65, 19.35, 37 and 85.5 GHz (dual polarization), and 21 GHz (vertical polarization only). The TMI Gridded Oceanic Rainfall Product, also known as TMI Emission, consists of 5 degree by 5 degree monthly oceanic rainfall maps using TMI Level 1 data as input. Statistics of the monthly rainfall, including number of samples, standard deviation, goodness-of-fit (of the brightness temperature histogram to the lognormal rainfall distribution function) and rainfall probability are also included in the output for each grid box. Spatial coverage is between 40 degrees North and 40 degrees South owing to the 35 degree inclination of the TRMM satellite. TMI brightness temperature histograms at 1 degree intervals are generated based on the 19, 21 and 19-21 GHz combination channels obtained from the Level 1B (calibrated brightness temperature) TMI product. Monthly rainfall indices over the ocean are derived by statistically matching monthly histograms of brightness temperatures with model calculated rainfall Probability Distribution Functions (PDF) using the 19-21 GHz combination data. Retrieved monthly rainfall data must pass a quality test based on the quality of the PDF fit. The data are stored in the Hierarchical Data Format (HDF), which includes both core and product specific metadata applicable to the TMI measurements. A file contains 12 arrays of rainfall data and supporting information each of dimension 72 x 16, with a file size of about 40 KB (uncompressed). The HDF-EOS "grid" structure is used to accommodate the actual geophysical data arrays. There is 1 file of TMI 3A11 data produced per month.
- API
TRMM Microwave Imager (TMI) Gridded Oceanic Rainfall Product (TRMM Product 3A11) V7
nasa-test-0.demo.socrata.com | Last Updated 2015-07-20T04:52:56.000ZThe Tropical Rainfall Measuring Mission (TRMM) is a joint U.S.-Japan satellite mission to monitor tropical and subtropical precipitation and to estimate its associated latent heating. TRMM was successfully launched on November 27, at 4:27 PM (EST) from the Tanegashima Space Center in Japan. The TRMM Microwave Imager (TMI) is a nine-channel passive microwave radiometer, which builds on the heritage of the Special Sensor Microwave/Imager (SSM/I) instrument flown aboard the Defense Meteorological Satellite Program (DMSP) platforms. Microwave radiation is emitted by the Earth's surface and by water droplets within clouds. However, when layers of large ice particles are present in upper cloud regions - a condition highly correlated with heavy rainfall - microwave radiation tends to scatter at frequencies above 19 GHz. The TMI detects radiation at five frequencies chosen to discriminate among these processes, thus revealing the likelihood of rainfall. The key to accurate retrieval of rainfall rates by this method is the deduction of cloud precipitation consistent with the radiation measurement at each frequency. The TMI frequencies are 10.65, 19.35, 37 and 85.5 GHz (dual polarization), and 21 GHz (vertical polarization only). The TMI Gridded Oceanic Rainfall Product, also known as TMI Emission, consists of 5 degree by 5 degree monthly oceanic rainfall maps using TMI Level 1 data as input. Statistics of the monthly rainfall, including number of samples, standard deviation, goodness-of-fit (of the brightness temperature histogram to the lognormal rainfall distribution function) and rainfall probability are also included in the output for each grid box. Spatial coverage is between 40 degrees North and 40 degrees South owing to the 35 degree inclination of the TRMM satellite. TMI brightness temperature histograms at 1 degree intervals are generated based on the 19, 21 and 19-21 GHz combination channels obtained from the Level 1B (calibrated brightness temperature) TMI product. Monthly rainfall indices over the ocean are derived by statistically matching monthly histograms of brightness temperatures with model calculated rainfall Probability Distribution Functions (PDF) using the 19-21 GHz combination data. Retrieved monthly rainfall data must pass a quality test based on the quality of the PDF fit. The data are stored in the Hierarchical Data Format (HDF), which includes both core and product specific metadata applicable to the TMI measurements. A file contains 12 arrays of rainfall data and supporting information each of dimension 72 x 16, with a file size of about 40 KB (uncompressed). The HDF-EOS "grid" structure is used to accommodate the actual geophysical data arrays. There is 1 file of TMI 3A11 data produced per month.
- API
Surface Turbulent Fluxes, 1x1 deg Daily Grid, Set1 V2c
nasa-test-0.demo.socrata.com | Last Updated 2015-07-20T04:51:34.000ZThese data are the Goddard Satellite-based Surface Turbulent Fluxes Version-2c (GSSTF2c) Dataset recently produced through a MEaSUREs funded project led by Dr. Chung-Lin Shie (UMBC/GEST, NASA/GSFC), converted to HDF-EOS5 format. The stewardship of this HDF-EOS5 dataset is part of the MEaSUREs project, http://earthdata.nasa.gov/our-community/community-data-system-programs/measures-projects/surface-turbulent-fluxes-esdr http://earthdata.nasa.gov/our-community/community-data-system-programs/measures-projects GSSTF version 2b (Shie et al. 2010, Shie et al. 2009) generally agreed better with available ship measurements obtained from several field experiments in 1999 than GSSTF2 (Chou et al. 2003) did in all three flux components, i.e., latent heat flux [LHF], sensible heat flux [SHF], and wind stress [WST] (Shie 2010a,b). GSSTF2b was also found favorable, particularly for LHF and SHF, in an intercomparison study that accessed eleven products of ocean surface turbulent fluxes, in which GSSTF2 and GSSTF2b were also included (Brunke et al. 2011). However, a temporal trend appeared in the globally averaged LHF of GSSTF2b, particularly post year 2000. Shie (2010a,b) attributed the LHF trend to the trends originally found in the globally averaged SSM/I Tb's, i.e., Tb(19v), Tb(19h), Tb(22v) and Tb(37v), which were used to retrieve the GSSTF2b bottom-layer (the lowest atmospheric 500 meter layer) precipitable water [WB], then the surface specific humidity [Qa], and subsequently LHF. The SSM/I Tb's trends were recently found mainly due to the variations/trends of Earth incidence angle (EIA) in the SSM/I satellites (Hilburn and Shie 2011a,b). They have further developed an algorithm properly resolving the EIA problem and successfully reproducing the corrected Tb's by genuinely removing the "artifactitious" trends. An upgraded production of GSSTF2c (Shie et al. 2011) using the corrected Tb's has been completed very recently. GSSTF2c shows a significant improvement in the resultant WB, and subsequently the retrieved LHF - the temporal trends of WB and LHF are greatly reduced after the proper adjustments/treatments in the SSM/I Tb's (Shie and Hilburn 2011). In closing, we believe that the insightful "Rice Cooker Theory" by Shie (2010a,b), i.e., "To produce a good and trustworthy 'output product' (delicious 'cooked rice') depends not only on a well-functioned 'model/algorithm' ('rice cooker'), but also on a genuine and reliable 'input data' ('raw rice') with good quality" should help us better comprehend the impact of the improved Tb on the subsequently retrieved LHF of GSSTF2c. This is the Daily (24-hour) product; data are projected to equidistant Grid that covers the globe at 1x1 degree cell size, resulting in data arrays of 360x180 size. A finer resolution, 0.25 deg, of this product has been released as Version 3. The GSSTF, Version 2c, daily fluxes have first been produced for each individual available SSM/I satellite tapes (e.g., F08, F10, F11, F13, F14 and F15). Then, the Combined daily fluxes are produced by averaging (equally weighted) over available flux data/files from various satellites. These Combined daily flux data are considered as the "final" GSSTF, Version 2c, and are stored in this HDF-EOS5 collection. There are only one set of GSSTF, Version 2c, Combined data, "Set1" It contains 9 variables: "E" 'latent heat flux' (W/m**2), "STu" 'zonal wind stress' (N/m**2), "STv" 'meridional wind stress' (N/m**2), "H" 'sensible heat flux' (W/m**2), "Qair" 'surface air (~10-m) specific humidity' (g/kg), "WB" 'lowest 500-m precipitable water' (g/cm**2), "U" '10-m wind speed' (m/s), "DQ" 'sea-air humidity difference' (g/kg) "Tot_Precip_Water" 'total precipitable water' (g/cm**2) The double-quoted labels are the short names of the data fields in the HDF-EOS5 files. The "individual" daily flux data files, produced for each individual satellite, are also available in HDF-EOS5, although from differe...
- API
GPM GROUND VALIDATION NASA S-BAND DUAL POLARIMETRIC (NPOL) DOPPLER RADAR IFLOODS V2
nasa-test-0.demo.socrata.com | Last Updated 2015-07-20T04:47:13.000ZThe GPM Ground Validation NASA S-Band Dual Polarimetric (NPOL) Doppler Radar IFloods V2 data set was collected from April 30, 2013 to June 16, 2013 near Traer, Iowa as a part of the Global Precipitation Measurement Mission (GPM) Iowa Flood Studies (IFloodS) campaign. The NASA NPOL radar, developed by a research team from Wallops Flight Facility, is a fully transportable and self-contained S-band (10 cm), scanning dual-polarimetric, Doppler research radar that collected and operated nearly continuously during the IFloodS field campaign. The GPM Ground Validation NASA S-Band Dual Polarimetric (NPOL) Doppler Radar IFloodS V2 data is available in Universal [Radar] Format (UF).
- API
Wire Insulation Incorporating Self-Healing Polymers (WIISP) Project
nasa-test-0.demo.socrata.com | Last Updated 2015-07-20T05:44:05.000ZNextGen Aeronautics, Inc. and their partner, Virginia Tech, propose to develop a self-healing material for wire insulation using a class of poly(ethylene-co-methacrylic acid) (EMAA) and poly(tetramethylene oxide) ionomer polymers. The self-healing property of these materials is strongly correlated with the thermal processes that occur during and after damage initiation. Recent experimental results have demonstrated that penetration of the polymer by a projectile causes localized heating near the puncture. The heating then causes a localized melt elastic response which serves to close the puncture and 'heal' the polymer. Since self-healing has already been demonstrated using these materials, the major technical challenge of this STTR effort is to stimulate the localized melt elastic response that has been shown to initiate self-healing. Our concept is to incorporate a magnetically-response phase into the insulating polymer for the purpose of causing localized heating during high-frequency excitation of the polymer. This magnetic phase will be located close to the electrical conductor. Localized heating will cause flow into the crack and, upon cooling, the crack will close over the wire and eliminate the exposure of the bare wire.