Eosc/easybuild - Revision history

Andreku at 16:15, 5 November 2021

2021-11-05T16:15:48Z

2021-01-28T14:47:31Z

‎Toward a Blueprint

2021-01-28T14:46:51Z

‎Toward a Blueprint

2021-01-28T14:38:01Z

‎Toward a Blueprint

2021-01-28T14:35:05Z

‎References

2020-10-21T10:21:27Z

‎References

2020-10-20T15:57:27Z

‎Desk Pilot

2020-10-20T15:48:11Z

‎Desk Pilot

2020-10-20T15:30:46Z

‎Desk Pilot

2020-10-20T15:27:12Z

‎Important stuff to remember

← Older revision		Revision as of 16:15, 5 November 2021
Line 1:		Line 1:
		+	[[Eosc/easybuild/modules\|Current modules]]
		+
	= Background =		= Background =

← Older revision		Revision as of 14:47, 28 January 2021
Line 51:		Line 51:

	we should consider alternative ways of naming, versioning, and organizing collections of modules. one scenario is for a user to activate a specific python version, then a CUDA version, and then the set of available modules becomes available.		we should consider alternative ways of naming, versioning, and organizing collections of modules. one scenario is for a user to activate a specific python version, then a CUDA version, and then the set of available modules becomes available.
		+
		+	[https://easybuilders.github.io/easybuild-tutorial/hmns/ Hierarchical naming scheme]?

	= References =		= References =

@@ Line 48: / Line 48: @@
 not all dimensions apply to all modules: Python not to non-python code; MKL only to codes that requires BLAS-like optimization; CUDA only to gpu-enabled code.
-putting all of these parameters into the module name is not the most direct path to a happy user experience.
+putting all of these parameters into the module name, i.e. 'fully explicit naming', is not the most direct path to a happy user experience.  that's almost what we currently have, though CUDA is missing, for this philosohpy.
 = References =

@@ Line 45: / Line 45: @@
 in other words, there are some parameters that we want to be able to vary flexibly, yielding a multi-dimensional matrix of different specific configurations.
 need to decide which dimensions to support.
 putting all of these parameters into the module name is not the most direct path to a happy user experience.
 = References =

@@ Line 31: / Line 31: @@
 specific: for example, CUDA versions are independent of
 toolchains, so their modules should be toolchain-agnostic.
 = References =

@@ Line 33: / Line 33: @@
 = References =
 Compute Canada: https://www.youtube.com/watch?v=_0j5Shuf2uE
-Jülich & Ghent: http://easybuilders.github.io/easybuild/files/eb-jsc-hust16.pdf
+EESSI: https://eessi.github.io/docs/

@@ Line 28: / Line 28: @@
 To distinguish system-wide from NLPL-specific modules,
 we would want to prefix the names of our own modules with 'nlpl-'.
 = References =

@@ Line 26: / Line 26: @@
 not include its own version of the core Python intepreter,
 nor of the MKL, CUDA, or cuDNN libraries.
 = References =

@@ Line 14: / Line 14: @@
 with the MKL backend, the other without (using the default, which we
 believe is OpenBLAS).
 Ideally, this choice near the bottom of the dependency tree
 should not propagate into the higher-level modules, i.e. we would
 hope to have only once instance of the SciPy bundle or TensorFlow,
 and they would interoperate seamlessly with either choice for NumPy.
 = References =