Project summary template

# Project summary template Here’s a more concise, half-page template that simplifies the structure while still capturing the essential information about the project outcomes and learnings: --- ### **Technical Project Summary** **Project Name:** **Round:** **Consultant(s) Involved:** --- ### **Project Overview** - **Summary of the Need/Problem:** A brief statement summarizing the project's need or problem. - **Main Outcomes and Deliverables:** Key results (software, data, publications) and links to where they can be accessed (repositories, DOIs, etc.). --- ### Highlights Noteworthy support or solutions provided by the consultanta, as well as challenges. --- ### **Lessons and Recommendations** - **Key Learnings:** Main lessons learned that could benefit future projects. - **Recommendations for Future Work:** Brief recommendations for similar projects or improvements in the process. --- ### **Additional Notes** - optional and free --- # #29 Geodykes monitoring system ### **Technical Project Summary** **Project Name:** Geodykes monitoring system **Round:** 4 **Consultant(s) Involved:** Jose Carlos Urra, Selin Kubilay, (Elviss Dvinkiss participated in the discovery phase) --- ### **Project Overview** - **Summary of the Need/Problem:** Researchers and water management stakeholders needed a system to monitor and analyze sensor data from dykes in response to weather conditions and climate change. The goal was to develop a platform that collects, presents, and monitors this data efficiently via a user-friendly dashboard. - **Main Outcomes and Deliverables:** - A web-based monitoring system, including a RESTful API built with FastAPI, a PostgreSQL relational database, and an interactive dashboard implemented using Dash. - Links to resources: - GitHub repository: [https://github.com/TUDelft-GeoDykes/geodykes-fastapi](https://github.com/TUDelft-GeoDykes/geodykes-fastapi) --- ### Highlights** Key support included the selection and implementation of the technology stack (FastAPI, PostgreSQL, Dash) and guidance on modularity and scalability of the system to ensure ease of maintenance and future upgrades. The researcher prototyped a solution that guided the implementation of a more advanced version. This was ideal, and relates to the question we ask in the forms about having a prototype, or reference solution. --- ### **Lessons and Recommendations** - **Key Learnings:** Collaborative data modeling with researchers significantly improved the accuracy and representation of field measurements. Using FastAPI ensured high performance in handling real-time requests, while the repository pattern provided flexibility for future database substitutions. - **Recommendations** Take the time to study something new or at least get familiar with methodologies for certain projects. For example in this project we had to learn how to do data modeling and relational DB design. --- ### **Additional Notes** The project started as a consultation with no promises on hands on support at the begginning and it ended up being supported through out the whole call period. Stay open to these kind of situations. --- # #25 AI Water Networks ### **Technical Project Summary** **Project Name:** AI Water Networks **Round:** 4 **Consultant(s) Involved:** Jose Carlos Urra, Elviss Dvinkiss, Selin Kubilay participated in the discovery phase --- ### **Project Overview** - **Summary of the Need/Problem:** The project aimed to develop a scientific repository for code and data that meets publication requirements for reproducibility, readability, and proper management. - **Main Outcomes and Deliverables:** - Code and data ready for scientific publication. - Releases, citation, licensing, DVC integration, and guides created. - Archived data and proper version control. - Results can be accessed via: - GitHub repository: [https://github.com/alextremo0205/SWMM_GNN_Repository_Paper_version](https://github.com/alextremo0205/SWMM_GNN_Repository_Paper_version) - Dataset link: [https://doi.org/10.4121/fec1e3de-9586-4a61-b3a1-02382592e52c](https://doi.org/10.4121/fec1e3de-9586-4a61-b3a1-02382592e52c) - Code repository: [https://doi.org/10.4121/989a0d3d-3b4d-47c7-8677-31c5975f9dec](https://doi.org/10.4121/989a0d3d-3b4d-47c7-8677-31c5975f9dec) - Published paper: [https://doi.org/10.1016/j.watres.2024.122396](https://doi.org/10.1016/j.watres.2024.122396) --- ### Highlights For the DCC a main challenge was the breakdown of the project in different areas of focus. Data management, Machine Learning workflows, software, and data version control. Rescoping to focus on publishing ready code, rather than generic solution to solve many problems. Decoupling dependencies, modules, and making the code portable, reproducible, configurable for different environments. Implementing DVC and reproducibility was challenging for the applicant also. --- ### **Lessons and Recommendations** - **Key Learnings:** - Simple things like .env files, using python modules, or reproducing is very appreciated by PhDs. - Thinking by default that code will be archived and not continuously developed. Ideally as an artifact that is part of a scientific publication. FAIR becomes more criticall in this context. - **Recommendations for Future Work:** - Don't assume by default that code will live forever assume that it will end its life once a publication is granted. - Only in the context of tools, services, packages, etc. It makes sense to have a more continuous view on the software lifecycle. --- ### **Additional Notes (optional)** - Encouragement to colleagues: The project was a success, and DCC support was instrumental in achieving publication-ready results. Would recommend others to apply for future calls for support. - A nice beer to close up the project is always good ;) ---