Update feature branch before pulling into development

Author: NicolasJPosey

.github/workflows/tests.yml

@@ -70,6 +70,14 @@ jobs:
       if: always() && steps.tscl.conclusion == 'success'
       run: diff ../Testing/RegressionTesting/TestOutput/test-small-connected-long-out.xml ../Testing/RegressionTesting/GoodOutput/Cpu/test-small-connected-long-out.xml
 
+    - id: ts911
+      name: run test-small-911
+      if: always() && steps.build.conclusion == 'success'
+      run: ./cgraphitti -c ../Testing/RegressionTesting/configfiles/test-small-911.xml
+    - name: verify test-small-911
+      if: always() && steps.tt.conclusion == 'success'
+      run: diff ../Testing/RegressionTesting/TestOutput/test-small-911-out.xml ../Testing/RegressionTesting/GoodOutput/test-small-911-out.xml
+
     - id: tm
       name: run test-medium
       if: always() && steps.build.conclusion == 'success'

.gitignore

@@ -27,6 +27,7 @@
 *.lib
 
 # Generated Files
+__pycache__/
 build/.cmake
 build/bin
 build/Simulator

CMakeLists.txt

@@ -290,8 +290,8 @@ include_directories(Testing/lib/GoogleTest/googletest-master/googletest/include)
 
 # Set CUDA_SEPERABLE_COMPILATION to ON for all libraries that contain .cpp files with device functions compiled as CUDA files
 if(ENABLE_CUDA)
-        set_property(TARGET Edges PROPERTY CUDA_STANDARD 11)
-        set_property(TARGET Vertices PROPERTY CUDA_STANDARD 11)
+        set_property(TARGET Edges PROPERTY CUDA_STANDARD 17)
+        set_property(TARGET Vertices PROPERTY CUDA_STANDARD 17)
         # Enables CUDA code in these libraries to be compiled into separate object files and then linked together
         set_property(TARGET Edges PROPERTY CUDA_SEPARABLE_COMPILATION ON)
         set_property(TARGET Vertices PROPERTY CUDA_SEPARABLE_COMPILATION ON)
@@ -360,45 +360,47 @@ add_executable(tests
         Testing/UnitTesting/RecorderFactoryTests.cpp
         Testing/UnitTesting/InputManagerTests.cpp
         Testing/UnitTesting/RNGFactoryTests.cpp
+	Testing/UnitTesting/GraphManagerTests.cpp
         Testing/Utils/ParameterManagerTests.cpp
         Testing/Utils/CircularBufferTests.cpp
-        Testing/UnitTesting/XmlRecorderTests.cpp)
+        Testing/UnitTesting/XmlRecorderTests.cpp
+        Testing/UnitTesting/Hdf5RecorderTests.cpp)
 
 # Links the Googletest framework with the testing executable
 target_link_libraries(tests gtest gtest_main)
 
 # Link the combined library into the 'tests' executable.
 target_link_libraries(tests combinedLib)
 
-add_executable(serialTest
-        Testing/RunTests.cpp
-        Testing/UnitTesting/SerializationTests.cpp)
+# add_executable(serialTest
+#         Testing/RunTests.cpp
+#         Testing/UnitTesting/SerializationTests.cpp)
 
-# Links the Googletest framework with the serialTest executable
-target_link_libraries(serialTest gtest gtest_main)
+# # Links the Googletest framework with the serialTest executable
+# target_link_libraries(serialTest gtest gtest_main)
 
-# Link the combined library into the 'serialTest' executable.
-target_link_libraries(serialTest combinedLib)
+# # Link the combined library into the 'serialTest' executable.
+# target_link_libraries(serialTest combinedLib)
 
-add_executable(deserialTest
-        Testing/RunTests.cpp
-        Testing/UnitTesting/DeserializationTests.cpp)
+# add_executable(deserialTest
+#         Testing/RunTests.cpp
+#         Testing/UnitTesting/DeserializationTests.cpp)
 
-# Links the Googletest framework with the deserialTest executable
-target_link_libraries(deserialTest gtest gtest_main)
+# # Links the Googletest framework with the deserialTest executable
+# target_link_libraries(deserialTest gtest gtest_main)
 
-# Link the combined library into the 'deserialTest' executable.
-target_link_libraries(deserialTest combinedLib)
+# # Link the combined library into the 'deserialTest' executable.
+# target_link_libraries(deserialTest combinedLib)
 
-add_executable(serialFileAccessTest
-        Testing/RunTests.cpp
-        Testing/UnitTesting/SerializationFileAccessTest.cpp)
+# add_executable(serialFileAccessTest
+#         Testing/RunTests.cpp
+#         Testing/UnitTesting/SerializationFileAccessTest.cpp)
 
-# Links the Googletest framework with the serialFileAccessTest executable
-target_link_libraries(serialFileAccessTest gtest gtest_main)
+# # Links the Googletest framework with the serialFileAccessTest executable
+# target_link_libraries(serialFileAccessTest gtest gtest_main)
 
-# Link the combined library into the 'serialFileAccessTest' executable.
-target_link_libraries(serialFileAccessTest combinedLib)
+# # Link the combined library into the 'serialFileAccessTest' executable.
+# target_link_libraries(serialFileAccessTest combinedLib)
 
 # Clear ENABLE_CUDA, PERFORMANCE_METRICS and GPROF from the cache so it's reset for subsequent builds
 unset(ENABLE_CUDA CACHE)

CONTRIBUTING.md

@@ -12,43 +12,43 @@ For UW Bothell students interested in working in the BCL, we use a [shared repos
 
 ## Workflow
 
-- Please read up on Github basics (including [GitHub Issues](https://help.github.com/categories/managing-your-work-on-github/)).
+- Please read up on Github basics (including [GitHub Issues](https://docs.github.com/en/issues/tracking-your-work-with-issues)).
 - Seek the guidance of more senior lab members regarding how to get started. 
 - Please ***DO NOT WORK DIRECTLY ON THE MASTER BRANCH***.
 - Instead, please follow the lab workflow that follows.
 
-0. Review our [Code Formatting Etiquette](https://uwb-biocomputing.github.io/Graphitti/Developer/codingConventions.html) and [C++ design and Coding standards](https://uwb-biocomputing.github.io/Graphitti/Developer/cppStyleGuide.html). Your work will be rejected if it doesn't conform (in fact, your pull requests will fail our code style check in many cases).
+1. Review our [Code Formatting Etiquette](https://uwb-biocomputing.github.io/Graphitti/Developer/codingConventions.html) and [C++ design and Coding standards](https://uwb-biocomputing.github.io/Graphitti/Developer/cppStyleGuide.html). Your work will be rejected if it doesn't conform (in fact, your pull requests will fail our code style check in many cases).
 
-1. Your work should be in response to one or more _issues_. If you are planning to work on something that is a small part of an existing issue, then likely that issue is a placeholder "umbrella" that was generated in lieu of thinking through all related details. In that case, now is the time for you to think it through and break that issue down into actionable items — new issues that partially or completely replace the umbrella.
+2. Your work should be in response to one or more _issues_. If you are planning to work on something that is a small part of an existing issue, then likely that issue is a placeholder "umbrella" that was generated in lieu of thinking through all related details. In that case, now is the time for you to think it through and break that issue down into actionable items — new issues that partially or completely replace the umbrella.
 
-2. When creating an issue, ensure that it is not a duplicate of an existing one. At Graphitti, we value proper etiquette for issue management. The issue title should be concise and descriptive, starting with action verbs. The issue body should provide all the necessary details, including a description section and tasks section.
+3. When creating an issue, ensure that it is not a duplicate of an existing one. At Graphitti, we value proper etiquette for issue management. The issue title should be concise and descriptive, starting with action verbs. The issue body should provide all the necessary details, including a description section and tasks section.
 
-3. Assign yourself to those issue(s).
+4. Assign yourself to those issue(s).
 
-4. Create a new feature branch for your work. The branch name should be prefixed with issue number followed by a short description of the issue i.e., **issue-3141-add-documentation-cereal**. 
+For more information on our GitFlow, please review our [GitFlow Documentation](docs/Developer/GitFlowDiagram.md) to better understand our modifications regarding merging the development branch.
+
+5. Create a new feature branch for your work. The branch name should be prefixed with issue number followed by a short description of the issue i.e., **issue-3141-add-documentation-cereal**. 
 Use lowercase letters & hyphens to separate words. Additionally, you can add a comment to the issue(s) including a link to the feature branch (unless you are going to create a pull request right away).
 
-5. Make changes to the feature branch (commit/push).
+6. Make changes to the feature branch (commit/push).
 
-6. Create a pull request for your branch, whether early or later in your work, to merge into the development branch (not master). Start the pull request title with the issue number, such as **[ISSUE-3141] Add documentation on cereal**. 
+7. Create a pull request for your branch, whether early or later in your work, to merge into the development branch (not master). Start the pull request title with the issue number, such as **[ISSUE-3141] Add documentation on cereal**. 
 In the pull request description, tag your issue and provide a brief overview of the changes for the reviewer. Additionally, ensure to perform the following actions in the right-hand column of the pull request page:
 
   - Assign the pull request to yourself.
   - Attach appropriate labels to the pull request.
   - Link the issue(s) you're working on to this pull request (under "Development", for some reason).
 
-For more information on pull requests, you can read the following guide: [pull requests](http://help.github.com/pull-requests/)
+For more information on pull requests, you can read the following guide: [pull requests](https://docs.github.com/en/pull-requests)
 
-6. Before requesting a review of your pull request, *check that your haven't broken anything*. This means checking that all of our automated GitHub actions have passed their tests (this will show directly in the pull request) and that any required manual tests have passed. Some of our tests take a while to run, so rather than do them for every commit to a pull request, we just run them manually when such requests are close to done. Also, GitHub can only test the CPU version of the simulator, so you need to run GPU tests manually. If in doubt, ask someone.
+8. Before requesting a review of your pull request, *check that your haven't broken anything*. This means checking that all of our automated GitHub actions have passed their tests (this will show directly in the pull request) and that any required manual tests have passed. Some of our tests take a while to run, so rather than do them for every commit to a pull request, we just run them manually when such requests are close to done. Also, GitHub can only test the CPU version of the simulator, so you need to run GPU tests manually. If in doubt, ask someone.
 
-7. Request a review of your pull request. If you have a designated reviewer, ask that person; otherwise, ask Prof. Stiber or ask during a lab meeting who should review your pull request.
+9. Request a review of your pull request. If you have a designated reviewer, ask that person; otherwise, ask Prof. Stiber or ask during a lab meeting who should review your pull request.
 
-8. When your pull request is approved, you can merge it.
+10. When your pull request is approved, you can merge it.
 
-9. Once you've verified that the merge is done, you can delete your feature branch.
+11. Once you've verified that the merge is done, you can delete your feature branch.
 
 ***Please document what you've done***, not only in your commit messages but also with useful comments in code and via changes to the github pages content in the docs directory.
 
 ***Please write unit tests.*** Every time you touch a file, you should review the existing unit tests and think of at least one new one to add.
-
-

Contributors.md

@@ -72,6 +72,10 @@ Natalie Gonzales
 ## 2024
 Andrzej Dawiec 
 
+ChengHao Hsu
+
+Zaina Shaikh
+
 <!-- ---------------------------------------------------------------------------------- -->
 # Graduate
 

Simulator/Connections/Connections.cpp

@@ -89,8 +89,7 @@ bool Connections::updateConnections(AllVertices &vertices)
 }
 
 #if defined(USE_GPU)
-void Connections::updateSynapsesWeights(const int numVertices, AllVertices &vertices,
-                                        AllEdges &synapses,
+void Connections::updateSynapsesWeights(int numVertices, AllVertices &vertices, AllEdges &synapses,
                                         AllSpikingNeuronsDeviceProperties *allVerticesDevice,
                                         AllSpikingSynapsesDeviceProperties *allEdgesDevice,
                                         Layout &layout)

Simulator/Connections/Connections.h

@@ -32,6 +32,8 @@
 #include "Recorder.h"
 #include <log4cplus/loggingmacros.h>
 #include <memory>
+// cereal
+#include <cereal/types/memory.hpp>
 
 using namespace std;
 
@@ -74,6 +76,9 @@ class Connections {
    ///  Creates synapses from synapse weights saved in the serialization file.
    void createSynapsesFromWeights();
 
+   ///  Cereal serialization method
+   template <class Archive> void serialize(Archive &archive, std::uint32_t const version);
+
 #if defined(USE_GPU)
 public:
    ///  Update the weight of the Synapses in the simulation.
@@ -85,8 +90,7 @@ class Connections {
    ///  @param  allVerticesDevice    GPU address of the allVertices struct on device memory.
    ///  @param  allEdgesDevice   GPU address of the allEdges struct on device memory.
    ///  @param  layout              Layout information of the neural network.
-   virtual void updateSynapsesWeights(const int numVertices, AllVertices &vertices,
-                                      AllEdges &synapses,
+   virtual void updateSynapsesWeights(int numVertices, AllVertices &vertices, AllEdges &synapses,
                                       AllSpikingNeuronsDeviceProperties *allVerticesDevice,
                                       AllSpikingSynapsesDeviceProperties *allEdgesDevice,
                                       Layout &layout);
@@ -104,4 +108,13 @@ class Connections {
 
    log4cplus::Logger fileLogger_;
    log4cplus::Logger edgeLogger_;
-};
+};
+
+CEREAL_CLASS_VERSION(Connections, 1);
+
+///  Cereal serialization method
+template <class Archive> void Connections::serialize(Archive &archive, std::uint32_t const version)
+{
+   archive(cereal::make_nvp("edges_", edges_),
+           cereal::make_nvp("synapseIndexMap_", synapseIndexMap_));
+}

Simulator/Connections/NG911/Connections911.cpp

@@ -9,6 +9,7 @@
 #include "Connections911.h"
 #include "All911Edges.h"
 #include "GraphManager.h"
+#include "Layout911.h"
 #include "ParameterManager.h"
 
 void Connections911::setup()
@@ -106,7 +107,8 @@ BGSIZE Connections911::getEdgeToClosestResponder(const Call &call, BGSIZE vertex
    // Euclidean distance to the call's location.
    BGSIZE startOutEdg = synapseIndexMap_->outgoingEdgeBegin_[vertexIdx];
    BGSIZE outEdgCount = synapseIndexMap_->outgoingEdgeCount_[vertexIdx];
-   Layout &layout = Simulator::getInstance().getModel().getLayout();
+   Layout911 &layout911
+      = dynamic_cast<Layout911 &>(Simulator::getInstance().getModel().getLayout());
 
    BGSIZE resp, respEdge;
    double minDistance = numeric_limits<double>::max();
@@ -115,10 +117,8 @@ BGSIZE Connections911::getEdgeToClosestResponder(const Call &call, BGSIZE vertex
       assert(edges911.inUse_[outEdg]);   // Edge must be in use
 
       BGSIZE dstVertex = edges911.destVertexIndex_[outEdg];
-      if (layout.vertexTypeMap_[dstVertex] == requiredType) {
-         double xDelta = call.x - layout.xloc_[dstVertex];
-         double yDelta = call.y - layout.yloc_[dstVertex];
-         double distance = sqrt(pow(xDelta, 2) + pow(yDelta, 2));
+      if (layout911.vertexTypeMap_[dstVertex] == requiredType) {
+         double distance = layout911.getDistance(dstVertex, call.x, call.y);
 
          if (distance < minDistance) {
             minDistance = distance;
@@ -130,7 +130,7 @@ BGSIZE Connections911::getEdgeToClosestResponder(const Call &call, BGSIZE vertex
 
    // We must have found the closest responder of the right type
    assert(minDistance < numeric_limits<double>::max());
-   assert(layout.vertexTypeMap_[resp] == requiredType);
+   assert(layout911.vertexTypeMap_[resp] == requiredType);
    return respEdge;
 }