Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

General Wishlist - to be split in different issues! #5

Open
HerManNav opened this issue Jun 28, 2023 · 0 comments
Open

General Wishlist - to be split in different issues! #5

HerManNav opened this issue Jun 28, 2023 · 0 comments

Comments

@HerManNav
Copy link
Collaborator

#############################
Formato DIR-B
#############################

Antes de nada:

  • En revisión si adelante con la propuesta actual.

SFP 1 de Junio:

  • A modo de índice potenciales temas a considerar
  • NO TODOS MISMA IMPORTANCIA: En este momento, mera lista para no dejar ideas en este momento fuera

  • a) CÓDIGO:
    1.- Revisión criterio actual de comprobación OK escritura info en DIR-B (tras writefile + close, intento de bloqueo de fichero para verificar que proceso de escritura ha ido OK = SFP no claro si es eficiente/elegante/practica la solución actual)
    2.- Comportamiento cuando se tratan formatos "raros" (para asegurar la interoperabilidad, HDF5 soporta determinado tipos de datos ), en particular coma flotante de mucha precisión

  • b) USO.
    0.- feedback resto del grupo
    1.- test con imagen singularity en clusters BSC + verificar que Ok uso ficheros dir-b ubicación diferente "directorio actual"
    2.- pruebas de multiconcurrencia:
    -a) el propio HDF5 (en realidad, h5py)
    -b) nivel dir-b ==> analizar idoneidad de excluir multiconcurrencia
    3.- pruebas de tamaño de fichero dir-b == acorde a documentación no limitación en tamaño
    4.- análisis tamaño VS tiempo acceso == sobre el papel, no problema
    5.- otras funcionalidades de h5py/HDF5: escritura de modelos con compresión, utilización de chunks para escribir, links que permite direccionar info albergada en otros HDF5, etc.
    6.- análisis creación métodos adicionales para funcionalidad par añadir info adicional para soluciones (comentario de Artur: "incluir tiempo de ejecución" ==> SFP para una ejecución dada ¿en que momento está disponible esa info? ¿es off-line (en el sentido ya terminado un job que procesa n files en el log?)
    7- Analizar si para los casos de uso específicos (Hidrógeno, Utilities....) merece la pena heredar de la clase actual, con objeto de forzar que los atributos de las soluciones, hayan de contender determinados y fijados atributos.
    8.- merge de soluciones: ahora mismo el merge se realiza entre dos dir-b. No claro si merece la pena adaptar para "n"; posibles alternativas list comprehension o una mera inducción sobre lista ficheros
    9.- nuevo método: utilizar la funcionalidad de la introspección de python para habilitar que de forma automagica, el código del propio programa que se está ejecutando, se guarde como metadata.

  • Memoria CDTI (si adelante con el formato)
    1.- La clase está bastante documentada: llevar a cabo generación de documentación html con herramientas específicas (Sphinx, pydoctor, Natural Docs... ) == tomaría poco tiempo y luciría mucho
    2.- incluir como entregable: "establecimiento de protocolo estandarizado para intercambio de casos de uso desde Repsol-BSC a resto de miembros del consorcio"

@HerManNav HerManNav transferred this issue from another repository Mar 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant