Anàlisi i optimització de software científic per al disseny de fàrmacs

id178650   ANÀLISI I OPTIMITZACIÓ DE SOFTWARE CIENTÍFIC PER AL DISSENY DE FÀRMACS ALEX KELLER GARCÍA Director/a: ALBERTHERREROROSELLÓ(PHARMACELERA,SOCIEDADLIMITADA) Ponent:JOSEPLLOSAESPUNY(Departamentd'ArquitecturadeComputadors) Titulació:GrauenEnginyeriaInformàtica(Computació) Memòria del projecte Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech 29/06/2023 Índex 1. Abstract ......................................................................................... 5 1.1. Català ........................................................................................................... 5 1.2. English ........................................................................................................ 6 2. Introducció i contextualització ...................................................... 7 2.1. Context ........................................................................................................ 7 2.2. Glosari ........................................................................................................ 8 2.2.1. Cribratge Virtual ................................................................................ 8 2.2.2. Preparació de lligands ....................................................................... 9 2.2.3. Paral·lelització ................................................................................... 9 2.3. Identificació del problema ....................................................................... 10 2.4. Actors implicats ........................................................................................ 11 2.5. Justificació ................................................................................................ 12 2.6. Aspectes legals del projecte ...................................................................... 14 3. Abast del projecte ........................................................................ 14 3.1. Objectius del projecte ............................................................................... 14 3.2. Obstacles i riscos ....................................................................................... 15 3.3. Metodologia .............................................................................................. 15 3.3.1. Eines ................................................................................................. 15 4. Desenvolupament del projecte .................................................... 16 4.1. Profiling ..................................................................................................... 17 4.2. Implementació de HTSLib ....................................................................... 21 4.2.1. Resultats ........................................................................................... 24 4.3. Millora de la paral·lelització de la generació de conformers .................. 28 4.3.1. Resultats ........................................................................................... 31 4.4. Optimització de la transferència de dades entre nodes .......................... 35 5. Planificació temporal .................................................................. 36 5.1. Descripció de les tasques .......................................................................... 36 5.1.1. OD - Organització i Documentació .................................................. 36 5.1.2. PR - Profiling .................................................................................... 38 5.1.3. HTS - Implementar HTSlib ............................................................. 39 5.1.4. MP - Millorar paral·lelització de la generació de conformers ........ 40 5.1.5. OT - Optimitzar la transferència de dades entre nodes ................... 41 5.2. Taula resum .............................................................................................. 42 5.3. Diagrama de Gant .................................................................................... 43 5.4. Gestió del risc ........................................................................................... 44 5.5. Avaluació i modificacions respecte la planificació .................................. 44 6. Pressupost ................................................................................... 47 6.1. Costos de personal .................................................................................... 47 6.2. Costos de software ................................................................................... 48 2 6.3. Costos de hardware .................................................................................. 48 6.4. Costos associats a imprevistos ................................................................. 49 6.5. Cost de contingències ............................................................................... 49 6.6. Pressupost final ........................................................................................ 50 6.7. Control de gestió ...................................................................................... 50 6.8. Cost Final .................................................................................................. 51 7. Sostenibilitat ............................................................................... 52 7.1. Autoavaluació ............................................................................................ 52 7.2. Dimensió econòmica ................................................................................ 52 7.3. Dimensió ambiental ................................................................................. 53 7.4. Dimensió social ........................................................................................ 53 8. Conclusions ................................................................................. 54 8.1. Justificació de les competències ...................................................................... 55 9. Referències ................................................................................. 58 Índex de taules 1. Taula de tasques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2. Sou brut per treballador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3. Cost total de personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4. Costos de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5. Costos de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6. Càlcul dels costos associats a imprevistos . . . . . . . . . . . . . . . . . . . . . . . . . 50 7. Càlcul dels costos de contingències . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 8. Pressupost final del projecte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 9. Cost final del projecte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3 Índex de figures 1. Speed ups de Pharmscreen amb diferents llibreries de molècules . . . . . 13 2. Profiling inicial del virtual screening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3. Profiling inicial de la preparació de lligands . . . . . . . . . . . . . . . . . . . . . . . 20 4. Temps de lectura d’un fitxer d’entrada amb 1,663,827 molècules . . . . . 22 5. Temps de lectura multi-threading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Temps d’execució de Virtual Screening usant compressió BGZ . . . . . . . 24 7. Temps d’execució de Virtual Screening usant compressió GZ . . . . . . . . 25 8. Millora de Virtual Screening usant compressió GZ . . . . . . . . . . . . . . . . . 26 9. Millora de Virtual Screening usant compressió BGZ . . . . . . . . . . . . . . . . 26 10. Speed ups del cribratge virtual anteriors als canvis . . . . . . . . . . . . . . . . . 27 11. Speed ups del cribratge virtual posteriors als canvis . . . . . . . . . . . . . . . . 27 12. Execució de la preparació de lligands prèvia als canvis . . . . . . . . . . . . . . 31 13. Execució de la preparació de lligands posterior als canvis . . . . . . . . . . . 32 14. Execució incorrecte de la preparació de lligands posterior als canvis . . 33 15. Comparació de diferents granularitats en la generació de conformers . 35 16. Diagrama de Gantt de la planificació inicial . . . . . . . . . . . . . . . . . . . . . . . 44 17. Diagrama de Gantt actualitzat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4 1. Abstract 1.1. Català PharmScreen és una eina de cribratge virtual desenvolupada per Pharmacelera, utilitzada per a la descoberta de fàrmacs mitjançant la predicció de l'afinitat i activitat de molècules candidates envers objectius farmacològics. Aquest treball de fi de grau té com a objectiu millorar la paral·lelització del software de PharmScreen per optimitzar l'ús dels recursos dedicats a les simulacions. Durant un període de cinc mesos, s'ha treballat en la implementació i millora de la paral·lelització emprant les llibreries OpenMP ( Open Multi-Processing ) i MPI ( Message Passing Interface ). Tot i que PharmScreen ja feia servir aquestes llibreries per a la paral·lelització, no s'aprofitaven totalment els recursos durant les simulacions. La primera part del projecte consisteix a identificar les àrees de millora durant la simulació amb múltiples processadors, i posteriorment implementar aquestes millores. PharmScreen consta de dos mètodes d'execució diferenciats, i s'ha treballat en cadascun d'ells per separat. En el cas del cribratge virtual, s'ha millorat la lectura dels fitxers d'entrada usant la llibreria HTSLib, que permet cerques remotes en fitxers comprimits, i s'han redissenyat les classes de lectura de fitxers del software. Aquestes millores han suposat un augment d'eficiència d'aproximadament el 30% fent servir els 7 nodes del clúster, i del 10% en utilitzar només 1 node. Pel que fa al segon mètode, la preparació dels lligands, s'ha millorat la distribució de la càrrega computacional dividint el fitxer inicial en petits trossos ( chunks ) i distribuint-los de manera desigual i segons la demanda entre els nodes. Això ha permès una millora d'aproximadament el 25% usant els 7 nodes del clúster. 5 1.2. English PharmScreen is a virtual screening tool developed by Pharmacelera, used for drug discovery through the prediction of affinity and activity of candidate molecules towards pharmacological targets. This thesis aims to improve the parallelization of PharmScreen software to optimize the utilization of resources dedicated to simulations. Over a period of five months, work has been done on the implementation and improvement of parallelization using the OpenMP (Open Multi-Processing) and MPI (Message Passing Interface) libraries. Although PharmScreen already used these libraries for parallelization, the resources were not fully utilized during simulations. The first part of the project consists of identifying areas for improvement during simulation with multiple processors and subsequently implementing these enhancements. PharmScreen consists of two distinct execution methods, and work has been done on each of them separately. In the case of virtual screening, the reading of input files has been improved using the HTSLib library, which allows remote searches in compressed files, and the file reading classes of the software have been redesigned. These improvements have resulted in an efficiency increase of approximately 30% using all 7 nodes of the cluster and 10% when using only 1 node. Regarding the second method, ligand preparation, the distribution of computational load has been improved by dividing the initial file into small chunks and distributing them unevenly and according to demand among the nodes. This has allowed for an improvement of approximately 25% using the 7 nodes of the cluster. 6 2. Introducció i contextualització El descobriment de fàrmacs és un procés polifacètic que ha jugat un paper crucial en el desenvolupament de la medicina moderna. Implica la identificació i el desenvolupament de nous medicaments per a abordar una àmplia gamma de malalties. El procés de descobriment de fàrmacs comença amb la identificació d'una potencial diana de fàrmacs, com una proteïna o un gen específic que està implicat en un procés de malaltia. Un cop identificat un objectiu, els investigadors comencen a dissenyar i provar compostos que poden interaccionar amb l'objectiu i modular la seva activitat. Els mètodes computacionals han esdevingut cada vegada més importants en el procés d'identificació d'objectius en el descobriment de fàrmacs. Un enfocament clau és l'ús de la bioinformàtica, que implica l'aplicació d'eines computacionals i algorismes per analitzar conjunts de dades biològiques a gran escala. 2.1. Context Aquest document té com a objectiu descriure tots els factors relacionats amb la gestió del projecte que té com a títol Anàlisi i optimització de software científic per al disseny de fàrmacs . Aquesta tesi és un Treball de Fi de Grau (TFG) emmarcat dins del pla d’estudis del Grau en Enginyeria Informàtica, en la menció de computació, impartit a la Facultat d’Informàtica de Barcelona (FIB) de la Universitat Politècnica de Catalunya (UPC). El projecte s’ha dut a terme en la modalitat d’empresa, concretament a Pharmacelera SL i consisteix en el desenvolupament d’un dels seus softwars principals: PharmScreen . Pharmacelera SL és una empresa de Barcelona especialitzada en el procés d’identificació de potencials candidats a fàrmacs. Pharmacelera aprofita la IA i els algoritmes d'aprenentatge automàtic per analitzar grans conjunts de bases de dades químiques i biològiques. En fer-ho, té com a objectiu identificar els potencials candidats a fàrmacs d'una manera més eficient i eficaç que els mètodes tradicionals. L’empresa ofereix un conjunt d'eines per a l'acoblament molecular, el cribratge virtual i el modelatge predictiu, que permeten als investigadors identificar possibles objectius de fàrmacs i optimitzar els candidats a fàrmacs més ràpidament. 7 PharmScreen és un programari desenvolupat per la companyia Pharmacelera SL per al descobriment de fàrmacs basat en el cribratge virtual. El cribratge virtual és un mètode computacional utilitzat en el descobriment de fàrmacs per identificar potencials candidats a fàrmacs mitjançant el cribratge de grans biblioteques de compostos contra una proteïna diana. Una de les característiques clau de PharmScreen és la seva capacitat per manejar grans biblioteques de compostos. El programari pot detectar fins a diversos milions de compostos contra una proteïna diana, la qual cosa permet als investigadors identificar potencials candidats a fàrmacs de forma més eficient que els mètodes tradicionals de cribratge experimental. No obstant això, el procés de modelització i simulació molecular requereix recursos computacionals substancials, i el temps necessari per realitzar el cribratge virtual pot variar depenent de la complexitat de l'experiment del cribratge. Per fer front a aquest repte, PharmScreen empra una gamma d'algorit mes i tècniques de modelatge molecular per accelerar el procés de projecció virtual. Tot i això, aquest programari es continua desenvolupant per tal de millorar tant l’eficiència com els resultats. 2.2. Glosari A continuació faré una descripció dels conceptes més importants i necessaris per entendre i poder seguir la descripció del treball. 2.2.1. Cribratge Virtual El cribratge virtual és un procés computacional utilitzat en el descobriment de fàrmacs per identificar, seleccionar i analitzar de manera eficient un gran nombre de molècules candidates per a l'activitat farmacològica desitjada. Aquest procés es realitza mitjançant simulacions i càlculs computacionals per predir les propietats i l'afinitat d'una molècula amb un objectiu terapèutic específic, com ara una proteïna o un receptor. PharmScreen consta de dues parts separades en el seu procés de cribratge virtual: la preparació de lligands i el cribratge virtual en si mateix. 8 2.2.2. Preparació de lligands La preparació de lligands és l’etapa prèvia al cribratge virtual. Consisteix en la preparació i adaptació de les molècules lligand, és a dir, les molècules candidates que s'analitzen per a la seva interacció amb una diana terapèutica específica. Durant la preparació de lligands, es duen a terme diverses tasques per garantir que les molècules estiguin en un format òptim per a la seva anàlisi i avaluació en el context de l'objectiu terapèutic desitjat. Aquest procés implica diverses etapes, les més importants són: 1. Neteja i filtratge: Es realitza una neteja de les molècules per eliminar grups o fragments innecessaris o indesitjats. 2. Generació de conformers : Es generen diferents conformacions tridimensionals de les molècules per tenir en compte la seva flexibilitat i possibilitats d'interacció amb la diana terapèutica. Les conformacions són les diferents formes tridimensionals que una molècula pot adoptar en funció de les seves interaccions internes i amb l'entorn. 3. Optimització de lligand: Es fa una optimització computacional de les molècules per ajustar les seves energies i geometries, amb l'objectiu d'optimitzar les seves interaccions amb la diana terapèutica. 4. Assignació de paràmetres: Es determinen i assignen els paràmetres moleculars necessaris per a la simulació i anàlisi de la interacció lligand-receptor, com ara càrregues, masses atòmiques, constants de força, entre altres. 2.2.3. Paral·lelització La paral·lelització o computació paral·lela és un concepte que implica dividir tasques computacionals en múltiples processadors o recursos computacionals per a realitzar-les simultàniament. L'objectiu principal de la paral·lelització és augmentar la velocitat d'execució i millorar l'eficiència del càlcul, permetent que diverses tasques es desenvolupin alhora en lloc de manera seqüencial. Aquesta estratègia pot millorar el rendiment global i l'eficiència dels sistemes informàtics, així com aprofitar de manera eficient els recursos disponibles. 9 ● Jira: és una plataforma web que permet als equips seguir i gestionar el seu treball a través de fluxos de treball personalitzables, taulers de control i informes. L’usarem per dividir el projecte en petites tasques i facilitar d’aquesta manera el seguiment i el desenvolupament del projecte. ● Bitbucket: Bitbucket proporciona als usuaris un repositori de Git. Els equips poden emprar Bitbucket per gestionar i fer un seguiment dels canvis en el seu codi, col·laborar en projectes i revisar i fusionar els canvis de codi. L’usarem conjuntament amb Jira per separar els canvis fets en cada tasca i tenir un millor control de tots els canvis fets durant el projecte. A més a més, es treballarà en el mateix repositori del software i a mesura que es vagin implementant les millores s'aniran afegint també a l’aplicació del mercat. 4. Desenvolupament del projecte En aquest apartat es presentarà el desenvolupament del projecte, es detallaran específicament els problemes que s'han d'afrontar, el plantejament per a resoldre'ls i la manera com s'han solucionat finalment. El procés de desenvolupament es dividirà en quatre apartats, corresponents a les quatre tasques "tècniques" del projecte: el perfilament, on identificarem les possibles millores al programa i les tres tasques de millora, la implementació de HTSLib , la millora de la paral·lelització de la generació de conformers i la optimització de la transferència de dades entre els nodes. Abans de començar, és important destacar que PharmScreen compta amb dos mètodes d'execució: la preparació de lligands i el cribratge virtual. La preparació de lligands té dues tasques principals: en primer lloc, a partir de cada molècula d'entrada, genera un nombre variable de molècules noves anomenades conformers ; i, en segon lloc, realitza el càlcul d'una sèrie de paràmetres addicionals. D'altra banda, encara que els dos mètodes d'execució són recomanats per a una eficaç tasca de cribratge virtual, el segon mètode és el responsable de dur-lo a terme. 16 Tenint en compte que les dues execucions presenten un nivell elevat de complexitat, l'objectiu d'aquest treball és millorar l'escalabilitat de tots dos mètodes en la mesura del possible. 4.1. Profiling La primera part del projecte consisteix a identificar les principals àrees d'ampliació del programari mitjançant un perfilatge del programa. A partir d'aquesta anàlisi, es desenvoluparà una planificació temporal per abordar els problemes detectats i implementar les millores proposades, tal i com es detalla al capítol següent. Per a realitzar una anàlisi del codi i comparar-lo amb les modificacions realitzades per avaluar-ne el rendiment i quantificar-ne les millores, és essencial utilitzar la mateixa màquina i entorn d'execució. Les simulacions es duran a terme al clúster de treball, que és utilitzat pels companys i permetrà provar el programa amb llibreries de molècules de gran magnitud, afavorint una anàlisi òptima de la paral·lelització. El clúster consta de 7 processadors o nodes diferents, i cada node disposa de 32 fils de procés. Aquest treball, se centrarà exclusivament en l'eficiència de l'ús dels nodes, i per tant, totes les simulacions s'executaran amb el nombre màxim de fils disponibles. A la figura 2 es mostra el temps d'execució de la simulació de cribratge virtual dividit per seccions del programa. Com s’observa en la figura, en l'execució amb un únic node destaquen dues parts principals: la secció groga mostra el temps que el programa triga a realitzar una primera lectura necessària del conjunt de molècules d'entrada, mentre que la secció blava indica el temps de càlcul del cribratge virtual. En canvi, en l'execució amb diversos nodes, s'identifiquen tres seccions addicionals a la simulació. La secció blanca indica el temps d'espera d'un node mentre els altres nodes completen la seva part del càlcul, considerant aquest temps com a temps inactiu i amb l'objectiu de minimitzar-lo al màxim possible. La secció verda representa el temps de comunicació entre els diferents nodes un cop finalitzat el càlcul, durant el qual els nodes envien la informació processada al node mestre per generar el fitxer final. La secció vermella correspon al que anomenem " skip molecules " i representa el temps de lectura de cada node fins arribar a la primera molècula que ha de processar. 17 Aquest procés es realitza per distribuir la tasca dividint el fitxer d'entrada en tantes parts iguals com nodes hi hagi, de manera que cada node haurà de recórrer el fitxer fins arribar a la seva secció. Cal destacar que el node 0 no requereix gaire temps per realitzar aquesta lectura, ja que comença directament amb la primera molècula d'entrada, mentre que l'últim node sempre necessita més temps per aquesta tasca, ja que ha de processar l'última secció del fitxer. També es pot observar que a mesura que s'utilitzen més nodes, l'últim node triga més en realitzar aquesta lectura, ja que amb més nodes les seccions de càlcul són més petites i, per tant, el principi de l'última secció és més llunyà. Figura 2: Profiling inicial del virtual screening, es mostra el temps total de cada simulació dividit en: Groc: temps de lectura, Vermell: skip molecules, Blau: temps de computació; Blanc: temps d’espera; Verd: transferència de dades. Elaboració pròpia. 18 Com es pot observar a la Figura 2, el temps de computació mostra una escalabilitat considerablement bona, ja que amb set nodes el rendiment és aproximadament 6 vegades més ràpid. No obstant això, el temps de lectura inicial és sempre el mateix, ja que és necessari per a tots els nodes. Per desgràcia, l'escalabilitat de la transferència de dades, i especialment la de la part de la lectura fins a la secció assignada, és encara pitjor, ja que requereix més temps a mesura que s'utilitzen més nodes. Per aconseguir l'objectiu d'aquest projecte, que és millorar l'eficiència de la paral·lelització de PharmScreen , és crucial reduir o eliminar el temps dedicat a les parts del codi que no es poden paral·lelitzar de manera eficient. Per tant, una part important del projecte consistirà en eliminar el temps associat a la lectura fins a la secció assignada. Per fer-ho s’ha buscat una llibreria que permeti saltar d’una part d’un fitxer comprimit a una altre, eliminant d’aquesta manera el temps de lectura fins arribar a la secció del fitxer assignada. Després d’una cerca exhaustiva ens hem decidit per la llibreria HTSLib [4] de c. Un cop finalitzat el perfilatge del cribratge virtual, vam continuar amb la preparació dels lligands i vam realitzar un perfilatge similar. Els resultats es mostren a la Figura 3. Tot i que la lectura inicial es realitza de la mateixa manera que en el cas del cribratge virtual, aquesta té una importància menor ja que s'utilitzen fitxers d'entrada més petits i, per tant, no resulta un problema tan important. No obstant això, es fa evident el problema de la paral·lelització en la preparació dels lligands, ja que el temps d'espera dels nodes després de generar els conformers és considerablement elevat. Això indica que els nodes no s'estan aprofitant de manera eficient i provoca una manca d'escalabilitat. La raó d'aquesta situació és la distribució de la feina entre els diferents nodes. Aquesta distribució es realitza de la següent manera: primerament, es realitza una lectura del fitxer d'entrada per determinar el nombre de molècules a processar. A continuació, el mateix nombre de molècules és assignat a cada node i cada node processa les seves molècules assignades. Aquesta esdevindria una bona estratègia si totes les molècules tinguessin la mateixa càrrega de treball, però aquest no és el cas. Algunes molècules requereixen una generació de conformers amb un cost computacional molt més elevat que d'altres, la qual cosa implica que, tot i que tots els nodes tinguin el mateix nombre de molècules, un node amb molècules computacionalment més complexes trigui molt més temps a completar la seva tasca. 19 Per solucionar aquest problema, és necessari buscar una millor manera de dividir les molècules d'entrada entre els nodes, de manera que el temps d'espera dels nodes es redueixi al mínim possible. Figura 3: Profiling inicial de la preparació de lligands, es mostra el temps total de cada simulació dividit en: Groc: lectura inicial, Vermell: skip molecules, Blau: temps de computació; Blanc: temps d’espera; Verd: transferència de dades. Elaboració pròpia. Hem identificat un tercer punt de millora que tot i ser secundari, té com a objectiu reduir el temps dedicat a la transferència de dades. Encara que aquest aspecte pot afectar l'escalabilitat del cribratge virtual i la preparació dels lligands, el temps dedicat a aquesta tasca no és tan significatiu. 20 Actualment, la transferència de dades es realitza enviant els fitxers de sortida generats per cada node al node 0, que és el responsable de concatenar-los en un únic fitxer de sortida. La proposta per reduir el temps d'aquesta tasca consisteix a comprimir els fitxers abans de l'enviament, amb l'objectiu de reduir la seva mida i, per tant, el temps de transferència. Aquesta última part del treball s'ha plantejat en cas que hi hagi prou temps després d'acabar les altres dues tasques principals. Hem pres aquesta decisió perquè, tot i que el treball té una data límit a finals de juny, el meu contracte laboral amb Pharmacelera dura fins a finals de juliol. Així doncs, en cas que no hi hagi prou temps per completar aquest últim apartat, es realitzarà durant l'últim mes de treball disponible. 4.2. Implementació de HTSLib Com a primer pas, vam emprendre una investigació de la llibreria HTSLib i realitzar diverses proves per confirmar la seva idoneïtat per al nostre objectiu. Aquesta llibreria fa servir un format de fitxer anomenat BGZF, que és similar a la compressió GZ utilitzada a PharmScreen. La diferència és que el fitxer es divideix en blocs de màxim 64 KB i s'afegeix una capçalera a cada bloc, el que permet realitzar salts remots d'una línia del fitxer a una altra. HTSLib no només permet realitzar els salts de línia que necessitem, sinó que, a més a més, té un temps de lectura molt més ràpid en comparació amb la llibreria estàndard que s'utilitzava anteriorment. A la figura 4 es mostra la millora en el temps de lectura tant en fitxers de text normals com en fitxers comprimits en els formats GZ i BGZF. 21 Figura 4: Temps de lectura d’un fitxer d’entrada amb 1,663,827 molècules en format txt, gz i bgzf. De color blau es mostren els temps fent servir la llibreria standard i en groc fent servir la llibreria htslib. Elaboració pròpia. La figura 4 mostra clarament que la implementació de la llibreria HTSLib representaria una millora significativa en totes les operacions de lectura. La lectura dels arxius de text normals és 1.8 vegades més ràpida, la d’arxius GZ és 4 vegades més ràpida i la d’arxius BGZF arriba a una millora de quasi 10 vegades més ràpid. Això va conduir a la decisió d'utilitzar la llibreria no només per a les lectures dels fitxers en format BGZF, sinó també per a totes les lectures del programa. Aprofitant aquest canvi, es va dur a terme una actualització completa de totes les classes de lectura del software . Aquesta actualització era necessària, ja que aquesta part del codi era una de les més antigues i requerida d'una modernització. Aquesta part del projecte es pot dividir en 3 parts diferenciades. En primer lloc, hem eliminat les diferents classes de lectura de fitxers i n’hem creat una nova. Abans s'utilitzaven classes de lectura diferents per llegir diferents tipus de fitxers, com ara fitxers de llicència, fitxers interns generats pel programa i fitxers d'entrada. Ja que ens hem adonat que no era necessari tenir classes separades, així que hem decidit crear una sola classe més simplificada per a la lectura de tots els fitxers. Tot seguit, per tal de poder saltar d'una molècula del fitxer d'entrada a una altra sense haver de llegir tot el fitxer fins a trobar-la, hem implementat una funcionalitat per desar la posició de cada molècula del fitxer. Aquesta ha estat la segona part de la implementació d'HTSLib . Durant la primera lectura del fitxer, que es realitza sempre, anem enregistrant la posició d'inici de cada molècula en un vector, utilitzant una funció proporcionada per la llibreria HTSLib . 22 Finalment, hem modificat la secció skipMolecules per eliminar la lectura innecessària del fitxer fins a la secció assignada per a cada node. En lloc d'això, hem incorporat una funció d'HTSLib que permet realitzar cerques remotes en fitxers comprimits amb BGZ o en fitxers de text sense comprimir. Cal tenir en compte que aquesta cerca remota no funciona amb fitxers comprimits amb GZ, de manera que hem mantingut la mateixa implementació anterior per a aquest cas. Durant la implementació d'aquesta classe, hem descobert que HTSlib permet la lectura amb múltiples fils d'execució per accelerar encara més el procés. Després de realitzar diverses proves, hem comprovat que s'aconsegueix una millora considerable utilitzant dos fils d'execució addicionals, però amb més de dos fils no s'aprecia cap millora addicional. Per aquest motiu, hem inclòs aquesta opció de lectura com a predeterminada. A la figura 5 es mostren els resultats de les proves realitzades. Es pot observar que, tot i que l'ús de multithreading no afecta el rendiment en fitxers de text i comprimits amb GZ, sí que redueix el temps de lectura dels fitxers BGZ en més de la meitat. Figura 5: Temps de lectura d’un fitxer d’entrada amb 1,663,827 molècules en format txt, gz i bgzf, usant l’opció de lectura amb múltiples threads. La primera columna és usant la classe de lectura prèvia als canvis, la segona usant les classes de htslib sense l’opció multithreading i les demés usant l’opció amb un, dos i quatre threads. Elaboració pròpia. 23 4.2.1. Resultats Figura 6: Temps d’execució de Virtual Screening usant compressió BGZ. Es representen 7 simulacions diferents cada una amb un nombre diferent de nodes i amb un fitxer d’entrada de 1.663.827 molècules. Elaboració pròpia. Un cop s'ha completat tota la implementació, s'analitzen els resultats obtinguts. A la figura 6 i la figura 7 es mostren els temps de cada part de les simulacions utilitzant fitxers comprimits en GZ i BGZ, respectivament. Aquestes simulacions s'han realitzat utilitzant el mateix fitxer d'entrada aplicat durant el perfilatge, permetent així una comparació directa per avaluar la millora en el temps d'execució del programa. Com es pot observar, el temps de lectura és considerablement menor en ambdós casos, i en el cas del fitxer BGZ, s'elimina completament el temps dedicat a saltar-se les molècules fins a arribar a la secció assignada. 24 D'altra banda, el temps dedicat al càlcul del cribratge virtual també s'ha reduït lleugerament. Creiem que això és a causa de la millora en el temps de lectura, que també afecta durant el procés de càlcul. Figura 7: Temps d’execució de Virtual Screening usant compressió GZ. Es representen 7 simulacions diferents cada una amb un nombre diferent de nodes i amb un fitxer d’entrada de 1.663.827 molècules. Elaboració pròpia. Tot i que aquests resultats són molt positius, no podem considerar-nos satisfets havent provat els canvis amb només un fitxer d'entrada. Per això, hem realitzat proves amb 4 llibreries de molècules addicionals per observar si obtenim resultats similars. 25 Figura 13: Execució de la preparació de lligands posterior als canvis. Cada fila és un node durant la simulació i cada color és una tasca: blau: generació de conformers, blanc: temps mort d’espera, taronja: computació de paràmetres i verd: transferència de dades. Elaboració pròpia. A la figura 13 es mostra el resultat de la mateixa simulació utilitzant el nou executable. Podem observar que l'objectiu dels canvis ha estat assolit, ja que s'ha aconseguit reduir gairebé completament el temps d'execució. Això és gràcies a la millor distribució de la càrrega de treball entre els nodes. D'altra banda, també és notable un increment en el temps de càlcul dels paràmetres. Aquest augment es deu als canvis realitzats, ja que ara cada node genera un fitxer per a cada fragment calculat, en lloc d'un sol fitxer per a tot el node. Això implica treballar amb arxius més petits, el que redueix l'eficiència de la paral·lelització d'aquesta part i augmenta el temps de càlcul. Malgrat això, la millora en la generació de conformers és molt més significativa i supera l'empitjorament en la part de càlcul dels paràmetres. Per optimitzar el càlcul de paràmetres, una millor estratègia de paral·lelització seria assignar cada fitxer a un únic fil d'execució ( thread ). D'aquesta manera, no importaria treballar amb chunks més petits durant la generació de conformers , ja que el càlcul dels paràmetres seria realitzat per un sol fil d'execució. A més, l'objectiu futur de l'empresa és eliminar aquests fitxers intermitjos i calcular els paràmetres de les molècules en el mateix moment que es generen els conformers . Aquest canvi serà altament beneficiós, ja que a més d'eliminar els fitxers intermitjos, millorarà significativament la paral·lelització de tot el programa, ja que tots els càlculs es realitzaran de manera continua. Aquesta propera millora s'integrarà perfectament amb els canvis realitzats durant el projecte. 32 Altrament, hem identificat que en ocasions les simulacions presenten un temps d'execució anormalment llarg. A la figura 14 es mostra una simulació amb el mateix fitxer d'entrada, on es pot observar que un dels nodes triga considerablement més en completar la seva part de generació de conformers . Aquesta anomalia és atribuïble a un error en el codi, tot i que, a causa dels desafiaments durant el desenvolupament del projecte i les restriccions de temps, no hem pogut identificar plenament la causa. Durant les pròximes setmanes, treballarem per solucionar aquest error i assegurar-nos que sempre obtenim els resultats esperats. Figura 14: Execució incorrecte de la preparació de lligands posterior als canvis. Cada fila és un node durant la simulació i cada color és una tasca: blau: generació de conformers, blanc: temps mort d’espera, taronja: computació de paràmetres i verd: transferència de dades. Elaboració pròpia. A causa d'aquest problema, no s'han pogut realitzar uns experiments representatius de la millora real dels canvis, els quals es duran a terme un cop s'hagi solucionat aquest error. Tot i això, sabem que els canvis fets representen una gran millora per al programa i, amb els experiments que tenim, esperem un speed up de 6,5 amb 7 nodes i una millora aproximada del 25%. Aquests resultats s'han obtingut eliminant les simulacions defectuoses i, tot i que no els podem assegurar per l’existència de l’error, tenim bons indicis que apunten que un cop solucionat seran així. 33 A més a més, hem dut a terme algunes proves canviant la mida dels chunks per veure com afectava al temps d'execució. Com era d'esperar, a mesura que els chunks són més petits, la distribució de la computació està més equilibrada i el temps total de la simulació és menor. Els resultats d'aquests experiments es mostren a la figura 15, on es pot observar que a mesura que disminueix la mida dels chunks , també disminueix la diferència de temps dedicada a la generació de conformers , i per tant es redueix el temps d'espera dels nodes. A conseqüència de la reducció de la mida dels chunks , també es veu un petit augment en el càlcul de paràmetres, però aquest augment és molt menor en comparació amb el guany obtingut en la generació de conformers . Cal tenir en compte que l'ampliació de l'eficiència temporal mitjançant l'ús de chunks més petits implica una major quantitat de fitxers, la qual cosa pot afectar negativament l'eficiència en l'ús de l'espai d'emmagatzematge. Això significa que, tot i aconseguir una millora en el temps d'execució, és possible que es requereixi més espai per a emmagatzemar els fitxers addicionals generats durant el procés de paral·lelització. 34 Figura 15: Comparació d’utilitzar diferents granularitats en la generació de conformers. Les simulacions son de 32, 20, 10 i 5 molècules per chunk. Elaboració pròpia. 4.4. Optimització de la transferència de dades entre nodes Quan vam planificar les tasques del projecte, ja vam tenir en compte que aquesta última tasca potser no seria factible de completar dins del temps establert. Desafortunadament, així ha sigut. Tot i que no ha estat possible durant el desenvolupament del projecte, es finalitzarà durant el pròxim mes mentre encara estic treballant a Pharmacelera. 35 5. Planificació temporal En aquest apartat s'exposarà la planificació prèvia al treball, aquesta preparació s’ha fet amb l’objectiu de facilitar l’organització durant el projecte i per determinar si els objectius són assequibles en el temps disponible. Per tal de fer la planificació del treball de fi de grau amb l’estimació més exacte possible hem dividit el projecte en diferents tasques. L’elaboració del treball va iniciar el 13 de febrer i la seva finalització està prevista pel 29 de juny. La major part del treball es farà a la feina amb un contracte laboral de mitja jornada, per tant, significarà una dedicació diària de 4 hores, de dilluns a divendres. A més a més, està previst que una part del projecte es faci des de casa, majoritàriament la part de documentació. En total està previst que el treball finalitzi en 17 setmanes des de la data d’inici i comporti unes 504 hores de treball aproximadament. 5.1. Descripció de les tasques Les tasques s’han agrupat en 5 blocs. A la taula 1 s’hi mostra una taula amb totes les tasques i la seva duració estimada i a la figura 15 s’hi pot veure la planificació inicial del projecte en forma de diagrama de Gantt. 5.1.1. OD - Organització i Documentació Aquest bloc inclou totes les tasques relacionades amb la planificació prèvia, l’organització durant el projecte i la documentació del treball. Aquestes tasques són importants tenir-les en compte per què comporten una part important del projecte. OD.1 - Reunions setmanals Des de l’inici del projecte fins al final es faran un seguit de reunions per fer un seguiment del treball i prendre decisions i resoldre dubtes sobre el mateix. Es faran dues reunions setmanals d’una hora aproximadament cada una, una amb l’equip de desenvolupadors de Pharmacelera amb caràcter més general de totes les implementacions que s’estan fent i es faran al programari. L’altra reunió setmanal es farà amb el director del TFG per parlar més concretament del treball i de l’evolució d’aquest. 36 OD.2 - Lliurable 1: Definició de l’abast i contextualització Abans de començar el treball és important definir els objectius que es volen aconseguir amb aquest. Aquesta tasca inclou tant el temps dedicat individual com les hores de reunió amb el director per definir l’abast del projecte. Aquest apartat també inclou la redacció de la primera entrega per l’assignatura de GEP. OD.3 - Lliurable 2: Planificació temporal A continuació de la definició de l’abast s’ha definit concretament totes les tasques a desenvolupar durant el projecte. Amb les tasques definides s’ha fet una planificació de tot el treball amb les hores estimades per cada tasca i el temps necessari per fer el projecte. Amb això s’ha pogut determinar que l’abast decidit anteriorment és assequible amb el temps que es disposa per fer el treball. També s’inclou en aquesta tasca el temps dedicat a la redacció del segon lliurable de GEP i a la realització del diagrama de Gantt de la figura 16. OD.4 - Lliurable 3: Gestió Econòmica i sostenibilitat Aquest apartat està dedicat a la part del projecte relacionada amb la sostenibilitat, tant econòmica, social, com mediambiental. Com en els dos apartats anteriors, aquest també inclou la feina feta per al lliurable 3 de GEP. OD.5 - Lliurable 4: Document final Aquesta tasca està destinada a la redacció del document final de l’assignatura de GEP. Aquest document inclou tots els lliurables entregats anteriorment corregits i millorats seguint les indicacions del tutor de l’assignatura. A més a més, aquest document serà una primera versió del document final del treball de final de grau. OD.6 - Documentació Tot i que es preveu que la documentació es tingui en compte durant tot el transcurs del projecte aquesta tasca està enfocada en el temps dedicat a la redacció del document final del treball de fi de grau. Tenint en compte tota la feina relacionada amb la documentació feta prèviament i amb l’objectiu de fer un bon document final la dedicació estimada, al final del treball, és de 20 hores. 37 OD.7 - Preparació de la defensa Un cop acabat el document final és necessari prepara la presentació davant del tribunal que avaluarà el TFG. La duració estimada per a la preparació del material de suport i del guió és de 15 hores. 5.1.2. PR - Profiling L’objectiu general del TFG és l’optimització del programa PharmScreen de Pharmacelera. Per a dur a terme aquest objectiu el primer pas imprescindible és identificar les regions del codi amb més marge de millora, perquè estan implementades de manera ineficient o perquè poden ser optimitzades d’alguna manera, per exemple paral·lelitzant-les. Per fer el profiling s’ha de tenir en compte que el programa PharmScreen té dos mètodes d’execució: ligand preparation i virtual screening . Aquests dos mètodes fan dues coses diferents i, per tant, s’hauran d’analitzar per separat. PR.1 - VS Tracing La primera part del profiling de la part de virtual screening es farà amb una classe ja implementada a PharmScreen utilitzada per rastrejar el temps utilitzat en qualsevol regió definida per l’usuari. Aquesta classe fa servir funcions de llibreries de c++ i podrà ser modificada segons les necessitats. A més a més, s’usarà aquesta tasca per guardar els temps de cada regió del codi per comparar-los amb els temps resultants de les optimitzacions i els canvis realitzats durant el projecte. PR.2 - LP Tracing Aquesta tasca és igual que l’anterior però analitzant el codi corresponent a l’execució de ligand preparation de PharmScreen . Tant per aquesta tasca com per l’anterior s’estima una duració de 20 hores cada una. PR.3 - Profiling Softwares L’última part del profiling està planificada per provar diferents softwares especialitzats en profiling i analitzar els resultats que s’obtinguin. Els softwares que es provaran són: valgrind [1], vampir [2] i TAU [3] . 38 5.1.3. HTS - Implementar HTSlib Durant el profiling s’han identificat dues regions del codi relacionades amb la lectura de grans fitxers comprimits de molècules. La primera és una funció anomenada countMolecules , aquesta funció fa un primer processament del fitxer d’entrada i compta el nombre de molècules que hi ha. El problema és que aquesta lectura es fa seqüencialment i en fitxers molt grans té un cost important. La segona regió identificada és una funció anomenada skipMolecules , l’objectiu d’aquesta funció és dividir les molècules a computar entre tots els nodes, com s’ha de llegir el fitxer seqüencialment el que fa la funció és llegir el fitxer fins que arriba a la molècula inicial assignada per a cada node. Aquesta funció té un cost molt elevat per a grans fitxers d’entrada, sobretot per al node que ha de computar les molècules del final del fitxer. Actualment, PharmScreen utilitza cap llibreria que permet l’accés remot a un fitxer comprimit. Per això, el primer bloc de tasques consistirà a implementar la llibreria HTSlib de Samtools [4] que sí que ho permet. HTS.1 - Investigar llibreria La primera tasca d’aquest bloc consisteix a investigar la llibreria per entendre com funciona i poder integrar-la de la millor manera possible. S’estima una duració de 10 hores per aquesta tasca HTS.2 - Provar funcionament A continuació, i amb el mateix objectiu d’entendre correctament el funcionament de la llibreria, es programarà un codi provar el funcionament i comparar l'eficiència de les funcions de la llibreria amb les utilitzades a PharmScreen . Es calcula un interval de temps de 35 hores per aquesta tasca. HTS.3 - Paral·lelitzar countMolecules Un cop s’hagi entès correctament el funcionament de la llibreria i s’hagi decidit com implementar-la a la funció de countMolecules serà el moment de portar-ho a terme. Aquesta tasca té una duració estimada de 40 hores i es farà per parts. Primer s’implementarà la llibreria per fer la lectura seqüencialment i després s’implementarà la paral·lelització. 39 HTS.4 - Integrar llibreria a PharmScreen Per tal d’eliminar la funció skipMolecules i poder accedir als fitxers d’entrada remotament durant la part computacional de virtual screening primer s’ha d’integrar completament la llibreria d’ HTSlib en els accessos als fitxers. S’estima que aquesta tasca duri 50 hores. HTS.5 - Eliminar skipMolecules A continuació d’haver integrat correctament la llibreria s’haurà d’eliminar la funció skipMolecules i canviar-la per una funció que accedeixi directament a les posicions desitjades del fitxer d’entrada. Aquestes posicions s’obtindran prèviament a la funció countMolecules . HTS.6 - Testar Finalment, després d’haver acabat tots els canvis serà el moment testar que tot funcioni correctament i d’afegir els tests necessaris per assegurar-se del funcionament correcte de les noves funcionalitats implementades. 5.1.4. MP - Millorar paral·lelització de la generació de conformers En el profiling de ligand preparation s’ha comprovat que no s’utilitzen el 100% dels recursos quan s’executa amb més d’un node. Això passa perquè la divisió de molècules per cada node està feta per blocs amb el mateix nombre de molècules, però hi ha molècules amb un cost computacional molt més elevat que altres i això provoca que els temps per blocs sigui molt variable. Per solucionar aquest problema es canviarà la divisió per blocs per una divisió en temps real. D’aquesta manera un node quan acabi la computació d’una molècula la següent d’una sola llista de molècules comuna per tots els nodes. MP.1 - Disseny Abans d’implementar aquest canvi s’haurà de dissenyar les modificacions necessàries i les seves implicacions. Es calcula que es tardarà unes 15 hores. 40 MP.2 - Implementació Per implementar els canvis s’estima que es tardarà unes 50 hores. MP.3 - Testar Per comprovar el correcte funcionament de tot el programa i comprovar la millora del temps aconseguida amb aquesta millora s’estima una duració de 20 hores. Aquesta tasca també inclou les proves per comprovar la millora de tots els canvis fets durant el projecte respecte a les proves fetes prèviament durant el profiling . 5.1.5. OT - Optimitzar la transferència de dades entre nodes Una altra regió de virtual screening que pot ser millorada és la part de transferència de dades entre nodes. Quan s’utilitzen múltiples nodes per a executar PharmScreen amb grans llibreries de molècules, la computació es divideix per als diferents nodes i un cop finalitzada la computació s’envien les dades al node màster. Aquesta transferència de dades ara mateix no és òptima, ja que s’envien els fitxers sense comprimir. Malgrat que l'estimació de la càrrega de treball dels apartats anteriors ja és prou àmplia, és molt difícil fer una estimació precisa del temps que requerirà el treball en conjunt. A més, és important tenir en compte que la data de finalització del meu contracte amb l'empresa difereix de la del TFG, i aquest factor s'ha tingut en consideració durant la planificació. Per tant, s'afegeix aquest últim apartat com a secundari. Tot i que farem tot el possible per abordar-lo com a part del treball, no podem garantir que es pugui completar dins del termini establert. OT.1 - Disseny La primera tasca d’aquest bloc consisteix a analitzar les implicacions que tindrà comprimir les dades abans d’enviar-les i dissenyar les modificacions necessàries. Per aquesta tasca s’estima una duració de 10 hores. 41 6.2. Costos de software Durant el projecte es treballaran amb diferents softwares molts dels quals són de codi obert o de franc. De tots els softwares que es faran servir només 3 són de pagament: Jira , Bitbucket i Slack . Tots tres són softwares relacionats amb la gestió de projectes i equips i, per tant, s’hauran de pagar pels dos treballadors durant els cincs mesos de duració del projecte. A la taula 4 es mostren els costos del software . Taula 4: Costos de software. Elaboració pròpia. 6.3. Costos de hardware Per a poder treballar conjuntament l’enginyer informàtic i el cap de projectes s'adquiriran dos portàtils personals. A més a més, com estem treballant amb un programari amb un cost computacional elevat és important tenir un bon ordinador per poder-hi treballar, a aquest ordinador hi podran accedir els dos treballadors. El cost dels perifèrics està inclòs en el de l’ordinador. L’amortització de la taula 5 s’ha calculat tenint en compte que dels quatre anys de vida útil estimada per als portàtils i l’ordinador, només s’utilitzaran durant 504 per a aquest projecte i la resta es farà servir per a altres projectes de l’empresa. La fórmula que s’ha seguit és aquesta: Amortització = Cost * 504 hores d'ús / (4 anys de vida útil * 220 dies laborables/any * 4 hores/dia) Taula 5: Costos de Hardware. Elaboració pròpia. 48 6.4. Costos associats a imprevistos Per últim, s’ha de calcular el possible cost associat a imprevistos que poden ocórrer durant el transcurs del projecte. Com s’ha definit a la planificació del treball durant el desenvolupament del projecte contemplem dos tipus d’imprevist: la necessitat de més temps de desenvolupament i la fallada d’algun dispositiu. En cas de necessitar-les es disposen de 60 hores extra per acabar la feina, aquestes 60 hores les hauria de fer l’enginyer informàtic i comportarien una supervisió per part del cap de projecte estimada en 10 hores. Per tant, en el pitjor cas comportaria un cost de 1.534 euros. S’estima un risc del 20% per aquest tipus d’imprevist. En canvi, per la fallida de dispositius s’estima un risc de només 5%, ja que són nou. A la taula 6 es mostren els costos calculats. Taula 6: Càlcul dels costos associats a imprevistos. Elaboració pròpia. 6.5. Cost de contingències Una vegada tenim tots els costos definits és important afegir un sobrecost per assegurar-nos que puguem finalitzar el projecte tot i que ens trobem algun obstacle o imprevist. Com no és un projecte que necessiti de molts components diferents s’ha decidit fixar en un 10% el sobrecost necessari. Taula 7: Càlcul dels costos de contingències. Elaboració pròpia. 49 6.6. Pressupost final Taula 8: Pressupost final del projecte. Elaboració pròpia. Finalment, a la taula 8 es presenta el cost total del projecte que serà de 14.173 euros. 6.7. Control de gestió Cal recordar, que el pressupost calculat en els apartats anteriors son estimacios. A mesura que vagi avançant el projecte el pressupost real es pot desviar de les estimacions que hem fet. Per evitar grans diferències s’han de definir mecanismes de control, així com indicadors numérics que ens permetin un seguiment del pressupost real. A continuació es descriuen els diferents indicadors numèrics que s’utilitzaran al llarg del projecte: 1. Desviació d’hores per tasca: hores_reals_tasca - hores_estimades_tasca 2. Desviació de cost de personal per total: hores_estimades * cost_hora_estimat - hores_reals * cost_hora_real 3. Desviació total de recursos Software + Hardware: cost_estimat_total - cost_real_total 4. Desviació cost d’imprevistos total: cost_estimat_imprevistos - cost_real_imprevistos Així doncs, durant el projecte, cada vegada que es finalitzi una tasca es compararàn les hores necessitades amb les estimades. D’aquesta manera també s’actualitzarà el pressupost i en cas d'imprevistos també es compararà amb el cost de contingència. 50 6.8. Cost Final Un cop finalitzat el termini del projecte fem un control del cost total teòric que li hauria suposat a l’empresa. Com no hi ha hagut imprevistos ni de hardware ni de software, únicament comptarem els costos extres de personal degut a que si que s’han necessitat les hores extres que es previen. Ens aprofitarem dels indicadors numèrics descrits al apartat anterior per justificar i visualitzar les modificacions en el cost final respecte el pressupost inicial. 1. Desviació d’hores per tasca: Tasca OD: 129 - 129 = 0 Tasca PR: 70 - 70 = 0 Tasca HTS: 180 - 140 = 40 Tasca MP: 85 - 225 = -140 Tasca Profiling: 40 - 0 = 40 2. Desviació de cost de personal per total: 11.801,00 - 13.335,00 = 1.534,00 3. Desviació total de recursos: Software: 220 - 220 = 0 Hardware: 416 - 416 = 0 4. Desviació cost d’imprevistos total: 492,00 - 1.534,00 = -1042 Així doncs i tal i com es mostra a la taula 9 el cost final és de 13.971,00 € que en comparació amb el pressupost inicial de 14.173,00 €, en sobrarien 202,00 €. Taula 9: Cost final del projecte. Elaboració pròpia. 51 7. Sostenibilitat 7.1. Autoavaluació Després d’haver respost a l’enquesta dirigida als universitaris per EDINSOST em puc fer una idea dels meus coneixements en relació amb la sostenibilitat. Personalment, crec que estic molt conscienciat en totes les dimensions de la sostenibilitat. Crec que durant tota la meva educació, tant universitària com anterior, ha sigut un aspecte important i que personalment sempre m’he pres seriosament. D’altre banda m’ha sorprès el meu desconeixement en relació a una part de la terminologia emprada durant l’enquesta i per tant considero que hauria de millorar el meu coneixement més teòric. Finalment, és la primera vegada que poso en pràctica els meus coneixements en relació a la sostenibilitat en un projecte d’aquestes magnituds i estic satisfet tant amb el resultat com amb l’aprenentatge obtingut. 7.2. Dimensió econòmica Tenint en compte que desenvolupo el meu TFG en una empresa privada la sostenibilitat econòmica és molt important. Tot i que el pressupost presentat anteriorment no és el cost real del projecte per Pharmacelera, opino que he fet una bona estimació del cost. Aquesta diferència es veu principalment en el cost del personal, que és la major part del pressupost, on l’estimació del sou està basada en els sous que es cobren de mitjana a Espanya per cada posició i no corresponen amb el meu sou personal. Tot i que he calculat el cost del projecte estimant els costos de els ordinadors que he utilitzat i les hores que hi he dedicat, jo no he decidit els recursos a dedicar, per tant no he pogut prendre cap decisió per reduir costos. No obstant, és d'especial interès per l’empresa invertir en la millora de PharmScreen, ja que el món del descobriment de fàrmacs és molt competitiu i totes les millores tant d’eficiència com de resultats són importants per sobresortir davant dels competidors. 52 7.3. Dimensió ambiental Considero que la realització d'aquest projecte té un impacte ambiental limitat, ja que l'únic cost ambiental atribuïble és el dels ordinadors utilitzats i la seva respectiva energia consumida, especialment pel clúster que requereix una quantitat considerable d'energia. No obstant això, aquest consum energètic no s'incrementa a causa del meu projecte, ja que els ordinadors i el clúster són utilitzats per altres companys de treball i no es desconnecten mai. Això vol dir que, encara que no hagués realitzat aquest projecte, l'energia consumida pels ordinadors i el clúster hauria estat aproximadament la mateixa. Una opció per reduir l'impacte energètic podria ser utilitzar menys ordinadors. No obstant això, aquesta opció no s'ha pogut implementar ja que els ordinadors són necessaris per a altres projectes de l'empresa. Cap dels ordinadors utilitzats son nous, per tant, no es pot atribuir tot el cost ambiental dels ordinadors únicament a aquest projecte, i cal tenir en compte que els ordinadors continuaran sent utilitzats una vegada finalitzi aquest treball. Davant l'objectiu del projecte de reduir el temps d'execució de les simulacions de PharmScreen , es pot afirmar que el projecte ha contribuït a reduir el cost energètic de les simulacions. A mesura que l'execució es redueix en temps, es consumeix menys energia per part de les màquines on es du a terme. 7.4. Dimensió social Una de les principals motivacions personals per fer aquest projecte és el desig de contribuir, encara que sigui mitjançant una aportació minúscula, al camp dels fàrmacs i per extensió de la salut, amb l’objectiu d’estendre i millorar la vida de les persones. Tot i que, aquest projecte no tindrà cap impacte directe considero que tota aportació en el món de la salut, per petita que sigui, és benvinguda i positiva. A nivell personal, l’oportunitat de treballar en un software complex i amb un equip professional de programadors, m’ha ajudat a aprendre molt sobre diferents camps de la informàtica, especialment de la paral·lelització. 53 8. Conclusions En aquest treball de fi de grau s'ha realitzat una millora significativa en la paral·lelització del software de PharmScreen , una eina de cribratge virtual desenvolupada per Pharmacelera. Mitjançant l'ús de les llibreries OpenMP i MPI, s'han identificat i implementat diverses millores que han optimitzat l'ús dels recursos dedicats a les simulacions de PharmScreen . En la primera part del projecte, s'ha millorat l’eficiència en el cribratge virtual mitjançant l'ús de la llibreria HTSLib per a la lectura de fitxers d'entrada i el redisseny de les classes de lectura de fitxers. Això ha permès un aprofitament més eficient dels recursos del clúster, amb millores d'eficiència de fins al 30% amb 7 nodes i un 10% amb 1 node. En la segona part del projecte, s'ha millorat la distribució de la càrrega computacional durant la preparació dels lligands. Mitjançant la divisió del fitxer inicial en petits chunks i la distribució desigual i a demanda entre els nodes, s'ha aconseguit una millora aproximada del 25% en l'ús del clúster. Malgrat que no s'ha pogut dur a terme una última tasca per reduir el temps de transferència de dades, el treball fet en aquest projecte ha proporcionat una millora significativa en la paral·lelització del programari de PharmScreen i ha contribuït a reduir el temps d'execució de les simulacions. En conclusió aquest treball ha demostrat la importància de la paral·lelització en les simulacions de PharmScreen i ha obert la porta a futures millores en l'ús dels recursos i la reducció del temps de càlcul. Les tècniques i els avenços implementats en aquest projecte poden ser aplicats en altres àmbits de la computació d’altes prestacions. 54 8.1. Justificació de les competències Finalment comentarem en detall quines son les principals competències específiques de computació que s’han vist involucrades en el projecte. CCO1.1: Avaluar la complexitat computacional d'un problema, conèixer estratègies algorísmiques que puguin dur a la seva resolució, i recomanar, desenvolupar i implementar la que garanteixi el millor rendiment d'acord amb els requisits establerts. [En profunditat] L'objectiu principal d'aquest projecte ha estat millorar l'eficiència de PharmScreen i optimitzar l'ús dels recursos computacionals disponibles. Durant el desenvolupament d'aquest treball, s'ha realitzat un anàlisi exhaustiu de les estratègies utilitzades en el software existent i s'han explorat diferents alternatives amb l'objectiu de millorar el rendiment i l'eficiència del programa. Aquest enfocament ha implicat la recerca i implementació de millores específiques per aconseguir un funcionament més eficient i optimitzat del sistema, així com l'avaluació dels resultats obtinguts per assegurar un ús més eficient dels recursos computacionals disponibles. CCO1.2: Demostrar coneixement dels fonaments teòrics dels llenguatges de programació i les tècniques de processament lèxic, sintàctic i semàntic associades, i saber aplicar-les per a la creació, el disseny i el processament de llenguatges . [Una mica] Durant el projecte, s'ha dedicat principalment al treball en C++, tot i que també s'han utilitzat altres llenguatges com C i Shell Script. És essencial tenir un alt nivell de coneixement en aquests llenguatges i durant el desenvolupament del projecte, s'ha adquirit encara més comprensió de com utilitzar-los de la millor manera possible. S'ha posat èmfasi en l'aplicació de les millors pràctiques i tècniques per optimitzar el rendiment i garantir l'eficiència en el codi desenvolupat en aquests llenguatges. 55 CCO2.1: Demostrar coneixement dels fonaments, dels paradigmes i de les tècniques pròpies dels sistemes intel·ligents, i analitzar, dissenyar i construir sistemes, serveis i aplicacions informàtiques que utilitzin aquestes tècniques en qualsevol àmbit d'aplicació . [Una mica] La intel·ligència artificial és una característica clau de PharmScreen per a realitzar un cribratge virtual satisfactori. En el nostre cas, en fer modificacions al programa per millorar l'eficiència en l'ús dels recursos, és crucial garantir que els resultats químics siguin consistents i que no hi hagi diferències en els resultats de les simulacions. CCO2.2: Capacitat per a adquirir, obtenir, formalitzar i representar el coneixement humà d'una forma computable per a la resolució de problemes mitjançant un sistema informàtic en qualsevol àmbit d'aplicació, particularment en els que estan relacionats amb aspectes de computació, percepció i actuació en ambients o entorns intel·ligents . [Una mica] Durant el meu projecte, he ampliat els meus coneixements de software i he aprofundit en l'ús de les tecnologies i els llenguatges de programació per a optimitzar l'ús dels recursos de PharmScreen. He adquirit habilitats en l'arquitectura del software, algoritmes i tècniques de cribratge virtual, i he desenvolupat solucions eficients. Aquesta experiència m'ha permès millorar la comprensió i l'aplicació de tècniques de desenvolupament per a obtenir un rendiment i una eficiència superiors en el programa. CCO2.3: Desenvolupar i avaluar sistemes interactius i de presentació d'informació complexa, i la seva aplicació a la resolució de problemes de disseny d'interacció persona computador . [Una mica] Durant el desenvolupament d’una aplicació informàtica és molt important tenir en compte l’experiència de l’usuari en l’ús del programa. Durant el projecte s’ha tingut en compte això intentant que els canvis tinguessin una mínima afectació negativa en l’usuari. 56 CCO3.1: Implementar codi crític seguint criteris de temps d'execució, eficiència i seguretat . [En profunditat] Aquesta competència tècnica ha estat fonamental per al desenvolupament del projecte, ja que el temps d'execució ha estat el principal indicador per identificar si s’estaven aconseguint els objectius proposats a l’inici del projecte. L'objectiu principal ha estat buscar l'eficiència màxima durant la implementació, sense comprometre els resultats de la simulació. Això ha suposat un repte, donada la complexitat del programa, però s'ha posat èmfasi en garantir la integritat dels resultats durant les millores realitzades. CCO3.2: Programar considerant l'arquitectura hardware, tant en assemblador com en alt nivell. [En profunditat] Per aconseguir una millora significativa en el temps d’execució del programa s’ha posat especial importància en usar els recursos computacionals disponibles de la manera més eficient possible. Tot i que no s’ha treballat en assemblador, s’han utilitzat les llibreries MPI i OpenMP per aconseguir millorar la paral·lelització existent i analitzar-la amb diferents característiques de hardware per tal d’assegurar un bon rendiment per a tots els usuaris. Amb els canvis implementats PharmScreen fa un millor ús dels recursos disponibles i la millora és més notable a mesura que s’augmenten els esforços computacionals. 57