If you/your team has a direct investment on the Taiga system separate from a compute allocation, access to your area is governed by an LDAP group that was created during the allocation onboarding; this group name often (but not always) looks like taiga_prj_XXXXX. Your group's PI (and whomever they've designated) are able to add you to the LDAP group that controls access to your allocation via NCSA's Identity portalPortal. Once you are a member of this group, you should have access to the data from any system that mounts Taiga across the center and the path will be the same.
HPC System Project Directory Access
Many NCSA compute environments leverage Taiga for their project space. For example, Delta's
/projects mount mount maps to the full path
/taiga/nsf/delta/ . Accessing data that is within compute environment project areas requires membership to the compute/system allocation for the system in question (be it Delta, HOLL-I, etc.). The compute allocation PI should be able to get you added to that group which will gain you access to this data, an example of this LDAP group would be delta_XXXX. Once in that group you should be able to access this data from all NCSA compute environments you have access to (via the full path) and on the system the allocation originates from via
Radiant allocations on Taiga live underneath the full path,
/taiga/ncsa/radiant/ and and are by default only available via NFS mount within Radiant instances associated with that allocation. If access of this data outside of Radiant is needed, please speak with the storage team by opening a ticket with the STO: Taiga component flag and someone from the storage team will assist you with your needs.
Data on Taiga is not backed up; and is only a single copy. It is recommended to back up critical data to an allocation on the Granite tape archive system or on another system on which you have an allocation.
Data Services Virtual Machines
Some groups may want/need to have virtual machines that can directly access their data on Taiga for things like: data serving, data portals, light data analysis/indexing, etc. For these use cases groups should procure a Radiant allocation of the appropriate size to operate these services. Radiant For VM attached storage, we recommend utilizing the Radiant openstack service. This is a separate service but will allow projects to have VMs to be able to handle their data pipeline/other requirementsis a scaleable way to give groups access to VM infrastructure that can access their data.