Code indexing in gitaly is broken and leads to code not being visible to the user. We work on the issue with highest priority.

Skip to content
Snippets Groups Projects

Resolve "Strategy pattern for DataSink"

Merged frey_m requested to merge 303-strategy-pattern-for-datasink into master

Closes #303 (closed)

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
81 }
82
83
84 void SDDSWriter::addDescription(const std::string& text,
85 const std::string& content)
86 {
87 os_m << "&description\n"
88 << indent_m << "text=\"" << text << "\",\n"
89 << indent_m << "contents=\"" << content << "\"\n"
90 << "&end\n";
91 }
92
93
94 void SDDSWriter::addParameter(const std::string& name,
95 const std::string& type,
96 const std::string& desc)
  • Developer

    I would add the value of the parameter here and store it as an item of a vector (or queue) of strings. Then I would add a method void SDDSWriter::writeParameters() which then writes the values in the correct order.

  • Author Maintainer

    Sure, I can change. It's anyway a bit more efficient. I would also like to change the way we do the dumping. We could add a new command ẀRITE that has TYPE and FREQ as attribute. This way what we dump is more flexible (e.g. as user might not be interested in the load balancing) and the number of OPTIONS would be reduced. But this would be another issue, I think.

  • Please register or sign in to reply
  • kraus
    kraus @kraus started a thread on commit 224dbfde
  • 232 this->writeValue(beam->get_DDy()); // 33
    233
    234 // Write head/reference particle/tail field information.
    235 this->writeValue(FDext[0](0)); // 34 B-ref x
    236 this->writeValue(FDext[0](1)); // 35 B-ref y
    237 this->writeValue(FDext[0](2)); // 36 B-ref z
    238
    239 this->writeValue(FDext[1](0)); // 37 E-ref x
    240 this->writeValue(FDext[1](1)); // 38 E-ref y
    241 this->writeValue(FDext[1](2)); // 39 E-ref z
    242
    243 this->writeValue(beam->getdE()); // 40 dE energy spread
    244 this->writeValue(beam->getdT() * 1e9); // 41 dt time step size
    245 this->writeValue(npOutside); // 42 number of particles outside n*sigma
    246
    247 if (Ippl::getNodes() == 1 && beam->getLocalNum() > 0) {
    • Developer

      These columns won't be written if there are no particles or all particles are stoppend by material. This means that the columns to the right are shifted to the left. We should write 6 zeros if there aren't any particles.

    • Author Maintainer

      Good point. Actually, I took the existing implementation. I think the idea behind these lines were that getLocalNum() == getTotalNum() in single core execution and that OPAL stops when there are no particles left. But sure, it's safer we write zeros instead since we don't know when OPAL checks that and really stops. I agree.

    • Author Maintainer

      Btw, what's actually the purpose of writing this? Isn't beam->RefPartR_m == beam->R[0] since it's single core execution? I think even in multi-core execution this is the case. It is true for the cyclotron tracker, but I don't know about ParallelTTracker.

    • Developer

      In ParallelTTracker beam->R[0] is a regular particle. In branch 303-strategy-pattern-for-datasink_proposal I don't write these columns if ParallelTTracker is used. To my knowledge this will also be the case for the cyclotron tracker once we have implemented #287 .

    • Author Maintainer

      Ok, so we don't write redundant info in this case. :smile: Yes, I also had #287 in my mind.

    • Please register or sign in to reply
    • kraus @kraus commented on commit c103f8df
      Developer

      @frey_m have a look at this commit for my ideas about SDDSWriter. Sofar I have only adapted the StatWriter. The other writers would have to be adapted likewise.

      The idea behind the SDDSDataRow class is that the order of the columns is only defined in one place.

    • Author Maintainer

      Yes, I like the idea! :smile:

    • Author Maintainer

      @kraus Why not adding the type and description to SDDSDataRow? We might get rid of filling the header separately. We'd just need to add another function in order to write the header first.

    • Please register or sign in to reply
  • frey_m
    frey_m @frey_m started a thread on commit c103f8df
  • 181 << OPAL_PROJECT_VERSION << " git rev. #" << Util::getGitRevision() << "\n"
    182 << (OpalData::getInstance()->isInOPALTMode()? "opal-t":
    183 (OpalData::getInstance()->isInOPALCyclMode()? "opal-cycl": "opal-env"))
    184 << std::endl;
    180 << "&end";
    181
    182 while (!paramValues_m.empty()) {
    183 os_m << "\n" << paramValues_m.front();
    184
    185 paramValues_m.pop();
    186 }
    187
    188 os_m << std::endl;
    185 189 }
    190
    191 void SDDSWriter::addDefaultParameters() {
  • frey_m
    frey_m @frey_m started a thread on commit 11b0ca5e
  • 16 16 #include "Ippl.h"
    17 17
    18 18 #include <iomanip>
    19
    19 #include <sstream>
    20
    21 namespace {
    22 std::string to_string(long double d) {
  • added Enhancement label

  • Developer

    In the attached patch I've removed unused code and cleaned a bit up.

  • frey_m added 1 commit

    added 1 commit

    • 92f332aa - applied Christof's patch 0001-cleaning-up.patch

    Compare with previous version

  • frey_m
  • kraus resolved all discussions

    resolved all discussions

  • snuverink_j
  • snuverink_j
  • snuverink_j
  • snuverink_j
  • snuverink_j
  • Great effort! It will take me a while to get through all the changed lines though.

  • frey_m added 1 commit

    added 1 commit

    Compare with previous version

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading