# data[].attributes.body
Since particle physics is becoming NHR customer in the future to operate the German WLCG Tier-2 compute resources a decent ethernet connection per WN and also WAN connection would be nice to have for the community.

# data[].attributes.body
Currently 100/0, unsure if GPU usage will be possible in the future

# data[].attributes.body
Both Nvidia+ AMD, though slight preference for Nvidia GPUs

# data[].attributes.body
Currently using both, but in future more GPUs

# data[].attributes.body
Currently 100/0, moving slowly to more GPU usage. Probably for the next HPC system still a lot of CPUs are needed

# data[].attributes.headline
Since Horeka should support all kinds of GPU applications, I think only Nvidia makes sense at the moment.

# data[].attributes.subject
Since Horeka should support all kinds of GPU applications, I think only Nvidia makes sense at the moment.

# data[].attributes.headline
For us, 20 percent pure CPU jobs, 80 percent GPU jobs. But ultimately, this should be projected from the workload numbers in 2023 and 2024 on the CPU and the accelerator queues. 

# data[].attributes.subject
For us, 20 percent pure CPU jobs, 80 percent GPU jobs. But ultimately, this should be projected from the workload numbers in 2023 and 2024 on the CPU and the accelerator queues. 

# data[].attributes.body
Currently everything is done with OpenACC in our code. All accelerators should be fine.

# data[].attributes.body
Code can use ARM but it is not stable and not all physics features are not supported.

# data[].attributes.body
At the moment, my code uses mainly GPUs, but CPU usage for some of additional computations

# data[].attributes.body
To my knowledge no one is running our code at ARM infrastructure. If anyone tried I don't know.

# data[].attributes.headline
Only if this does not cause a lot of overhead of porting/compiling software or being limited to specific software. It is essential that we can run standard machine learning libraries out of the box. 

# data[].attributes.subject
Only if this does not cause a lot of overhead of porting/compiling software or being limited to specific software. It is essential that we can run standard machine learning libraries out of the box. 

# data[].attributes.body
My code currently uses Nvidia, but there will be a AMD option in the near future - preference: currently tendency towards Nvidia, but might change

# data[].attributes.headline
AI + Robotics, mainly work on Nvidia GPUs. E.g. Transformers, and robotic simulation (Nvidia IsaacLab). The main reason behind is its easy to be used. But we are always open to AMD if it is competitive.

# data[].attributes.subject
AI + Robotics, mainly work on Nvidia GPUs. E.g. Transformers, and robotic simulation (Nvidia IsaacLab). The main reason behind is its easy to be used. But we are always open to AMD if it is competitive.

# data[].attributes.headline
We can only use Nvidia hardware for our research

# data[].attributes.subject
We can only use Nvidia hardware for our research

# data[].attributes.body
Some lab members use more GPU, some more CPU (machine learning graphs), but the overall trend is towards more GPU (GPU-based simulators available now)

# data[].attributes.headline
More and more language / fundation models are used in the AI community, which increase the requirement of the GPU hardwares. 

# data[].attributes.subject
More and more language / fundation models are used in the AI community, which increase the requirement of the GPU hardwares. 

# data[].attributes.body
Always more is needed;)

# data[].attributes.headline
Fast storage is more important than backed-up storage

# data[].attributes.subject
Fast storage is more important than backed-up storage

# data[].attributes.body
For compiling, installing packages, loading training data, etc., we often have to be very careful to avoid networked storage as it is way too slow. Things are on the parallel file system by default, but not much of our data really needs to be backed-up, as it's all on WandB.

# data[].attributes.headline
Queue system of slurm is a bit unclear, we observed the fresh new project can get a higher priority than the old but not exhausted project in slum. The jobs using the new project can just "jump" in the queue and start immediately. 

# data[].attributes.subject
Queue system of slurm is a bit unclear, we observed the fresh new project can get a higher priority than the old but not exhausted project in slum. The jobs using the new project can just "jump" in the queue and start immediately. 

# data[].attributes.body
Making data stored on HoreKa easily available to external partners who do not have direct access to the system would be appreciated.

# data[].attributes.body
For distributed discrete and combinatorial algorithms & applications, CPU(-only) nodes (with decent RAM/core) are very important to us.

# data[].attributes.body
Codes of the CFD (Computational Fluid Dynamics) are Memory-bound. Therefore, I think that those codes will continue using CPUs. If the number of CPUs will be reduced too much, many engineering problems will need to be reduced accordingly or even completely cancelled. This may lead to a change in the user-profile on the HoreKa2 systhem because CFD users will need to go to other machines.

Some applications like compressible (high speed) fluids require the use of double-precision arithmetics.

Sometimes, depending on the number of grid points per core (maybe around 1000 to 3000 points) the complete problem can fit into the L3-cache which can significantly accelerate the solution. So, I would prefer having a hardware with more L3-cache.

# data[].attributes.body
Our results from the CFD (Computational Fluid Dynamics) need to be processed and evaluated in many ways, also including additional postprocessing and visualization software. Therefore the data need to stay "hot" for a longer time. Therefore workspaces and more reliable memory (which is regularly backuped) like LSDF are important for CFD users. The speed of the memory here is not of importance.

# data[].attributes.headline
What do we do with our research data on LSDF or workspaces of HPC after the project is finished? Is there any archiving system available for this? 

# data[].attributes.subject
What do we do with our research data on LSDF or workspaces of HPC after the project is finished? Is there any archiving system available for this? 

# data[].attributes.body
We train large neural networks which requires only GPU

# data[].attributes.body
For any modern AI / Deep Learning application or research AMD is essentially unusable. This is mostly due to CUDA being the de-facto standard for the libraries and frameworks used (Tensorflow, PyTorch, JaX.... ), which have non or only very rudimentary support for AMD. I don't think this is particularly great, but it's the way it is and I don't see any signs of it changing anytime soon.