News and Announcements from OSG Operations > 3.3.26 and 3.4.1 Worker-node Tarballs Re-released

A minor configuration issue in the 3.3.26 and 3.4.1 worker-node tarballs
prevented the GFAL tools from functioning. We have created updated
tarballs with the correct configuration.

If you installed OSG worker-node tarballs directly, between July 12th and
18th, you should consider reinstalling them using the latest builds
(labeled as version 3.3.26-2 or 3.4.1-2). The tarball installations
on OASIS have been updated.

News and Announcements from OSG Operations > GOC Service Update - Tuesday, July 25th at 14:00 UTC

The GOC will upgrade the following services beginning Tuesday, July 25 at 14:00 UTC. The GOC reserves 8 hours in the unlikely event unexpected problems are encountered.

All Services
Operating system updates, reboots will be required. The usual HA mechanisms will be used, but some services will experience brief outages.

News and Announcements from OSG Operations > Announcing OSG CA Certificate Update

We are pleased to announce a data release for the OSG Software Stack.
Data releases do not contain any software changes.

This release contains updated CA Certificates based on IGTF 1.84:
- Updated ROSA root certificate with extended 20yr valitity (RO)
- Updated contact details for CyGrid CA following transition to CYNET (CY)
- Removed obsoleted KISTI-2007 trust anchor - replaced by KISTIv3 (KR)
- Removed expiring LACGrid trust anchor a9082267 (BR)
- Added UK Pathfinder AAAI CA 1 to unaccredited (misc) area (UK)

Release notes and pointers to more documentation can be found at:

https://www.opensciencegrid.org/bin/view/Documentation/Release3/Release3412

Need help? Let us know:

https://www.opensciencegrid.org/bin/view/Documentation/Release3/HelpProcedure

We welcome feedback on this release!

News and Announcements from OSG Operations > Announcing OSG Software version 3.3.26

We are pleased to announce OSG Software version 3.3.26.

Changes to OSG 3.3.26 include:
- Bug fix in LCMAPS plugin that could cause the HTCondor-CE schedd to crash
- osg-configure uses the new GUMS JSON interface
- The BLAHP properly requests multi-core resources for Slurm batch systems
- HTCondor-CE: send memory requirements to batch systems, whole node jobs
- Gratia probes: support whole node jobs, can include ClassAd attributes
- Bug fix to CVMFS client to able to mount when large groups exist
- GridFTP server now correctly uses plugin configuration
- gridftp-dsi-posix replaces the xrootd-dsi plugin, see release notes
- Enhanced gridftp-dsi-posix: MD5 checksum, support XRootD space tokens
- Bug fix for HDFS NameNode LeaseManager to prevent endless loop

Release notes and pointers to more documentation can be found at:
https://www.opensciencegrid.org/bin/view/Documentation/Release3/Release3326

Need help? Let us know:
https://www.opensciencegrid.org/bin/view/Documentation/Release3/HelpProcedure

We welcome feedback on this release!

News and Announcements from OSG Operations > Announcing OSG Software version 3.4.1

We are pleased to announce OSG Software version 3.4.1.

Changes to OSG 3.4.1 include:
- Bug fix in LCMAPS plugin that could cause the HTCondor-CE schedd to crash
- osg-configure uses the new GUMS JSON interface
- The BLAHP properly requests multi-core resources for Slurm batch systems
- HTCondor-CE: send memory requirements to batch systems, whole node jobs
- Gratia probes: support whole node jobs, can include ClassAd attributes
- Bug fix to CVMFS client to able to mount when large groups exist
- GridFTP server now correctly uses plugin configuration
- gridftp-dsi-posix replaces the xrootd-dsi plugin, see release notes
- Enhanced gridftp-dsi-posix: MD5 checksum, support XRootD space tokens
- HTCondor 8.6.4: BOSCO now works without CA certificates on remote cluster
- HTCondor 8.7.2: introducing the 8.7 series in the upcoming repository

Release notes and pointers to more documentation can be found at:
https://www.opensciencegrid.org/bin/view/Documentation/Release3/Release341

Need help? Let us know:
https://www.opensciencegrid.org/bin/view/Documentation/Release3/HelpProcedure

We welcome feedback on this release!

News and Announcements from OSG Operations > OSG Support of the Globus Toolkit

Many in the OSG community have heard the news about the end of support for the open-source Globus Toolkit.

What does this imply for the OSG Software stack? Not much: OSG support for the Globus Toolkit (e.g., GridFTP and GSI) will continue for as long as stakeholders need it. Period.

Note the OSG Software team provides a support guarantee for all the software in its stack. When a software component reaches end-of-life, the OSG assists its stakeholders in managing the transition to new software to replace or extend those capabilities. This assistance comes in many forms, such as finding an equivalent replacement, adapting code to avoid the dependency, or helping research and develop a transition to new technology. During such transition periods, OSG takes on traditional maintenance duties (i.e., patching, bug fixes and support) of the end-of-life software. The OSG is committed to keep the software secure until its stakeholders have successfully transitioned to new software.

This model has been successfully demonstrated throughout the lifetime of OSG, including for example the five year transition period for the BestMan storage resource manager. The Globus Toolkit will not be an exception. Indeed, OSG has accumulated more than a decade of experience with this software and has often provided patches back to Globus.

Over the next weeks and months, we will be in contact with our stakeholder VOs, sites, and software providers to discuss their requirements and timelines with regard to GridFTP and GSI.

Please reach out to goc@opensciencegrid.org with your questions, comments, and concerns.

A copy of this statement can be found at https://opensciencegrid.github.io/technology/policy/globus-toolkit.

Open Science Grid News > Machine learning insights into molecular science using the Open Science Grid

Computation has extended what researchers can investigate in chemistry, biology, and material science. Studying complex systems like proteins or nanocomposites can use similar techniques for common challenges. For example, computational power is expanding the horizons of protein research and opening up vast new possibilities for drug discovery and disease treatment.

Olexandr Isayev is an assistant professor at the School of Pharmacy, University of North Carolina (UNC) at Chapel Hill. Isayev is part of a group at UNC using machine learning for chemical problems and material science.

“Specifically, we apply machine learning to chemical and material science data to understand the data, find patterns in it, and make predictive models,” says Isayev. “We focus on three areas: computer-aided design of novel materials, computational drug discovery, and acceleration of quantum mechanical methods with GPUs (graphic processing units) and machine learning.”

For studying drug discovery, where small organic molecule binds to a protein receptor, Isayev uses machine learning to build predictive models based on historical collection of experimental data. “We want to challenge models and find a new molecule with better binding properties,” says Isayev.

Example of a protein model that Isayev and his group study. Courtesy image.

Similar to the human genome project, five years ago President Obama created a new Materials Genome Initiative to accelerate the design of new materials. Using machine learning methods based on the crystal structure of the material he is studying, Isayev can predict its physical properties.

“Looking at a molecule or material based on geometry and topology, we can get the energy, and predict critical physical properties,” says Isayev. “This machine learning allows us to avoid many expensive uses of numeric simulation to understand the material.”

The challenge for Isayev’s group is that initial data accumulation is extremely numerically time consuming. So, they use the Open Science Grid (OSG) to run simulations. Based on the data, they train their machine learning model, so the next time, instead of a time-consuming simulation model, they can use the machine learning model on a desktop PC.

“Using machine learning to do the preliminary screening saves a lot of computing time,” says Isayev. “Since we performed the hard work, scientists can save a lot of time by prioritizing a few promising candidate materials instead of running everything.”

For studying something like a photovoltaic semiconductor, Isayev selects a candidate after running about a thousand of quantum mechanical calculations. He then uses machine learning to screen 50,000 materials. “You can do this on a laptop,” says Isayev. “We prioritize a few—like ten to fifty. We can predict what to run next instead of running all of them. This saves a lot of computing time and gives us a powerful tool for screening and prioritization.”

On the OSG, they run “small density function (DFT) calculations. We are interested in molecular properties,” says Isayev. “We run a program package called ORCA (Quantum Chemistry Program), a free chemistry package. It implements lots of QM methods for molecules and crystals. We use it and then we have our own scripts, run them on the OSG, collect the data, and then analyze the data.”

“I am privileged to work with extremely talented people like Roman Zubatyuk,” says Isayev. Zubatyuk works with Isayev on many different projects. “Roman has developed our software ecosystem container using Docker. These simulations run locally on our machines through the Docker virtual environment and eliminate many issues. With a central database and set of scripts, we could seamlessly run hundreds of thousands of simulations without any problems.”

Finding new materials and molecules are hard science problems. “There is no one answer when looking for a new molecule,” says Isayev. “We cannot just use brute force. We have to be creative because it is like looking for a needle in a hay stack.”

For something like a solar cell device, researchers might find a drawback in the performance of the material. “We are looking to improve current materials, improve their performance, or make them cheaper, so we can move them to mass production so everyone benefits,” says Isayev.

“For us, the OSG is a fantastic resource for which we are very grateful,” says Isayev. “It gives us access to computation that enables our simulations that we could not do otherwise. To run all our simulations requires lots of computing resources that we cannot run on a local cluster. To do our simulation screening, we have to perform lots of calculations. We can easily distribute these calculations because they don’t need to communicate to each other. The OSG is a perfect fit.”


News and Announcements from OSG Operations > RE: What to expect from OSG 3.4

On May 30, we sent an e-mail outlining many of the changes to expect in OSG 3.4 and since then, we have released OSG 3.4.0 (details can be found here: https://twiki.opensciencegrid.org/bin/view/Documentation/Release3/Release340 ) and added relevant documentation. Most prominently, documentation is now available for installation and configuration of the LCMAPS VOMS plugin (https://twiki.opensciencegrid.org/bin/view/Documentation/Release3/InstallLcmapsVoms), including instructions to transition from edg-mkgridmap. Additionally, we have released our retirement policy and timelines for the following software:

  - GUMS (https://opensciencegrid.github.io/technology/policy/gums-retire/)
  - BeStMan (https://opensciencegrid.github.io/technology/policy/bestman2-retire/)
  - VOMS Admin Server (https://opensciencegrid.github.io/technology/policy/voms-admin-retire/)

As always, if there are any questions or concerns, please contact us at goc@opensciencegrid.org

News and Announcements from OSG Operations > Future support dates for OSG 3.3 sites

After last week's release of OSG 3.4.0, the software and release teams will begin the end-of-life process for the OSG 3.3 branch. This means that we will provide regular support to software in the OSG 3.3 stack until December 2017, and critical bug and security fixes until May 2018. The relevant text can be found below or at our release series support policy page (https://opensciencegrid.github.io/technology/policy/release-series/).

OSG supports at most two concurrent release series, current and previous, where the goal is to begin a new release series about every 18 months. Once a new series starts, OSG will support the previous series for at least 12 months and will announce its end-of-life date at least 6 months in advance. During the first 6 months of a series, OSG will endeavor to apply backward-compatible changes to the previous series as well; afterward, OSG will apply only critical bug and security fixes. When support ends for a release series, it means that OSG no longer updates the software, fixes issues, or troubleshoots installations for releases within the series. The plan is to maintain interoperability between supported series, but there is no guarantee that unsupported series will continue to function in OSG.

Condor Project News > HTCondor 8.7.2 released! ( June 22, 2017 )

The HTCondor team is pleased to announce the release of HTCondor 8.7.2. This development series release contains new features that are under development. This release contains all of the bug fixes from the 8.6.4 stable release. Enhancements in the release include: Improved condor_schedd performance by turning off file checks by default; condor_annex -status finds VM instances that have not joined the pool; Able to update an annex's lease without adding new instances; condor_annex now keeps a command log; condor_q produces an expanded multi-line summary; Automatically retry and/or resume http file transfers when appropriate; Reduced load on the condor_collector by optimizing queries; A python based condor_top tool. Further details can be found in the Development Version History and the Stable Version History. HTCondor 8.7.2 binaries and source code are available from our Downloads page.

Condor Project News > HTCondor 8.6.4 released! ( June 22, 2017 )

The HTCondor team is pleased to announce the release of HTCondor 8.6.4. A stable series release contains significant bug fixes. Highlights of this release are: Python bindings are now available on MacOSX; Fixed a bug where PASSWORD authentication could fail to exchange keys; Pslot preemption now properly handles custom resources, such as GPUs; condor_submit now checks X.509 proxy expiration. More details about the fixes can be found in the Version History. HTCondor 8.6.4 binaries and source code are available from our Downloads page.

News and Announcements from OSG Operations > GOC Service Update - Tuesday, June 27th at 14:00 UTC

The GOC will upgrade the following services beginning Tuesday, June 27th at 1400 UTC. The GOC reserves 8 hours in the unlikely event unexpected problems are encountered.

GRACC
- Fixed generation of GRACC summaries for HTCondor jobs that were removed.  Reprocessed old records with this issue as well.

Oasis
- Modifications of virtual machine host to allow oasis components to access USB ports.

VOMS
- Update voms-admin to 2.7.0-1.22 per request.

All services
- Operating system updates; reboots will be required. The usual HA mechanisms will be used, but some services will experience brief outages.

News and Announcements from OSG Operations > Announcing OSG CA Certificate and VO Package Updates

We are pleased to announce a data release for the OSG Software Stack.
Data releases do not contain any software changes.

This release contains updated CA Certificates based on IGTF 1.83:
- Added new trust anchor for accredited KISTI CA v3 (KR)
- Removed obsolete GEANT TCS G1 and G2 (old Comodo-backed) trust anchors

This release also contains VO Package v74:
- Fix the edg-mkgridmap entries for project8 and miniclean
- Add new VOMS entry for CIGI
- Add LIGO entry to GUMS template
- Fix vo-client ATLAS mappings

Release notes and pointers to more documentation can be found at:

https://www.opensciencegrid.org/bin/view/Documentation/Release3/Release3402

Need help? Let us know:

https://www.opensciencegrid.org/bin/view/Documentation/Release3/HelpProcedure

We welcome feedback on this release!

News and Announcements from OSG Operations > Announcing OSG Software version 3.4.0

We are pleased to announce OSG Software version 3.4.0.

OSG 3.4.0 is the start of a new release series. In this series we have
streamlined and consolidated the set of packages. This release contains
all the updates of the recent OSG 3.3.25 release.

This release also contains:
- HTCondor 8.6.3 - see release notes for upgrade information
- Frontier-squid 3.5.24-3.1 - see release notes for upgrade information
- GlideinWMS 3.3.2 in the Upcoming repository

Temporarily unavailable in OSG 3.4:
- HDFS - 3.x to be included in OSG 3.4 at a later date

No longer available in OSG 3.4:
- edg-mkgridmap - replaced by LCMAPS VOMS plugin
- GUMS - replaced by LCMAPS VOMS plugin
- BeSTMan 2 - replaced by Load Balanced GridFTP
- GLExec - replaced by Singularity
- VOMS Admin Server - being retired
- Globus GRAM - available from EPEL
- GIP and OSG Info Services - BDII servers retired

In addition to the list of packages in OSG 3.4, the release notes also
contain a comprehensive list of packages not carried forward from OSG 3.3.

Release notes and pointers to more documentation can be found at:

https://www.opensciencegrid.org/bin/view/Documentation/Release3/Release340

Need help? Let us know:

https://www.opensciencegrid.org/bin/view/Documentation/Release3/HelpProcedure

We welcome feedback on this release!

News and Announcements from OSG Operations > Announcing OSG Software version 3.3.25


We are pleased to announce OSG Software version 3.3.25.

Changes to OSG 3.3.25 include:
- lcmaps VOMS plugin mapping uses the first FQAN to behave similar to GUMS
- Update to XRootD 4.6.1
- Update to GlideinWMS 3.2.19
- HTCondor-CE: Add ability to request whole node jobs from the batch system
- Install default VO mapfile with osg-ce/osg-gridftp for lcmaps VOMS plugin
- voms-admin-server security update
- Fix osg-update-vos script to pick up new vo-client changes
- osg-configure can get the default allowed_vos from the lcmaps VOMS plugin
- osg-configure can use lcmaps VOMS plugin to get the default allowed VOs
- osg-ca-scripts now refers to repo.grid.iu.edu

Release notes and pointers to more documentation can be found at:

https://www.opensciencegrid.org/bin/view/Documentation/Release3/Release3325

Need help? Let us know:

https://www.opensciencegrid.org/bin/view/Documentation/Release3/HelpProcedure

We welcome feedback on this release!

Derek's Blog > StashCache

StashCache is a framework to distribute data across the Open Science Grid. It is designed to help opportunistic users to transfer data without the need for dedicated storage or frameworks of their own, like CMS and ATLAS have deployed. StashCache has several regional caches and a small set of origin servers. Caches have fast network connections, and sizable disk storage to quickly distribute data to the execution hosts in the OSG.

StashCache is named for the Stash filesystem located at the University of Chicago’s OSG-Connect service. It is primarily intended to be used to cache data from the Stash filesystem, though, data origins exist for other experiments.

Regional Caches Regional Caches

Components

The worker nodes are where the user jobs will run. The transfer tools are used on the worker nodes to download data from StashCache caches. Worker nodes are geographically distributed across the US, and will select the nearest cache based upon a GeoIP database.

StashCache Architecture StashCache Architecture

The caches are distributed to computing sites across the U.S. They are are running the XRootD software. The worker nodes connect directly to the regional caches, which in turn download from the Origin servers. The caching proxies discover the data origin by querying the Redirectors. The caching algorithm used is Least Recently Used (LRU). In this algorithm, the cache will only delete cached data when storage space is near capacity, and will delete the least recently used data first.

The origin servers are the primary source of data for the StashCache framework. StashCache was named after the Stash data store at the University of Chicago’s OSG-Connect service, but other origins also utilize the framework. The origin is the initial source of data, but once the data is stored on the Caches, the origin is no longer used. Updates to data on the origin are not reflected in the caches automatically. The caches treat the data from the origin as immutable, and therefore do not check for updates. If a user requires new data to be pulled into the cache, the name or location of the data on the origin must be changed.

Redirectors are used to discover the location of data. They are run only at the Indiana Grid Operations Center (GOC). The redirectors help in the discovery of the origin for data. Only the caching proxies communicate with the redirectors.

Tools to transfer

Two tools exist to download data from StashCache, CVMFS and StashCP. With either of these tools, the first step for users is to copy the data to the Stash filesystem. Once the user has an OSG-Connect account, they may copy their data to the /stash//public directory. Once there, both of the tools can view and download the files.

CVMFS (CERN Virtual Machine File System) is a mountable filesystem that appears to the user as a regular directory. CVMFS provides transparent access for users to data in the Stash filesystem. The namespace, such as the size and name of files, and the data are separate in the Stash CVMFS. CVMFS distributes the namespace information for the Stash filesystem over a series of HTTP Forward Proxies that are separate from the StashCache federation. Data is retrieved through the Stash proxies.

In order to map the Stash filesystem into CVMFS, a process is constantly scanning the Stash filesystem checking for new files. When new files are discovered, they are checksummed and the meta-data is stored in the CVMFS namespace. Since this scanning can take a while for a filesystem the size of Stash, it may take several hours for a file placed in Stash to be available through CVMFS.

Using CVMFS, copying files is as easy as copying files with any other filesystem:

$ cp /cvmfs/stash.osgstorage.org/user/<username>/public/… dest/

CVMFS access also has other features that are beneficial for Stash access. CVMFS will cache files locally so that multiple accesses to the same file on the same node will be very fast. Also, CVMFS can fallback to other nearby caches if the first fails.

StashCP is the second tool that can download data from StashCache. StashCP uses CVMFS above, as well as falling back to the caching proxies and eventually the origin. The order of operations that StashCP performs:

  1. Check for the file in CVMFS mount under /cvmfs/stash.osgstorage.org/…
  2. If CVMFS copy fails, connect directly to the nearest proxy and attempt to download the file.
  3. If the proxy fails, then connect directly to the origin server.

Since StashCP doesn’t rely on the CVMFS mount only, files are immediately available to transfer with StashCP.

StashCP is distributed with OSG-Connect’s module system. Using StashCP is nearly as simple as using the cp command:

$ module load  stashcp
$ stashcp /user/<username>/public/… dest/

Conclusions

The StashCache framework is very useful for downloading data to execution hosts across the OSG. It was designed to help opportunistic users to transfer data without the need for dedicated storage or frameworks of their own, like CMS and ATLAS have deployed.

StashCache has been used to transfer over 3 PB of data this year. Check out some of the papers written about using StashCache:

  • Derek Weitzel, Brian Bockelman, Duncan A. Brown, Peter Couvares, and Frank Wu ̈rthwein, Edgar Fajardo Hernandez. 2017. Data Access for LIGO on the OSG. In Proceedings of PEARC17, New Orleans, LA, USA, July 09-13, 2017, 6 pages. DOI: 10.1145/3093338.3093363 Online
  • Derek Weitzel, Brian Bockelman, Dave Dykstra, Jakob Blomer, and René Meusel, 2017. Accessing Data Federations with CVMFS. In Journal of Physics - Conference Series. Online

News and Announcements from OSG Operations > GOC Service Update - Tuesday, June 13th at 14:00 UTC

The GOC will upgrade the following services beginning Tuesday, June 13th at 14:00 UTC.  The GOC reserves 8 hours in the unlikely event unexpected problems are encountered.

Display
- Configuration management changes conclude

Jira
- Upgrade RAM to 4GiB, required by recent upgrade to 7.3

MyOSG
- VO SUMMARY output messages cleaned up to minimize root mail


Subscribe