Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Request for copies of config file and hwmap file along with daqconf_multiru_gen.info #235

Open
bieryAtFnal opened this issue Oct 13, 2022 · 4 comments
Assignees

Comments

@bieryAtFnal
Copy link
Contributor

At the moment, the command-line arguments that are passed to daqconf_multiru_gen are stored in an "info" file that is created in the top directory of the generated configuration.

It would be really great to also have copies of the input daqconf.json and hw_map.txt files that were used in generating the configuration stored somewhere for future reference.

If this functionality already exists, we can simple make a note in this Issue and mark it as unneeded...

@jcfreeman2 jcfreeman2 self-assigned this Oct 13, 2022
@plasorak
Copy link
Contributor

This is a good idea however the fact that the hardware map isn't a json file complicates things. All the files are uploaded to a mongodb in case the user wants to run a k8s run, and txt file won't work. I have another issue in dfmodules (I think) about this, the hardware map should be added to the dataflow configuration rather than in a standalone file.

@plasorak
Copy link
Contributor

Last call before I go and close this as "won't fix", because I feel we could still create a file that looks like:

{
 "hwmap": "# DRO_SourceID DetLink DetSlot DetCrate DetID DRO_Host DRO_Card DRO_SLR DRO_Link 
100 0 4 6 3 localhost 0 0 0
101 1 4 6 3 localhost 0 0 1"
}

and be named hwmap.json, as a temporary fix.

@bieryAtFnal
Copy link
Contributor Author

@plasorak , your temporary fix sounds reasonable to me, so I vote for going ahead with it, at least on develop branch(es).
My sense from our earlier discussion was A) we weren't sure whether it should go into v3.2.x or v3.3.0, and B) we would discuss possible implementations as part of a wider discussion about HWMap files, but in neither case did I imagine that we would "not fix" this, but rather reassign it to v3.3.0.

@plasorak
Copy link
Contributor

You're right, should be deferred rather than closed.

In the mean time this should solve this problem: #239

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants