To implement correct digitization on the side boundary pads for both GEM and...

@v.singhal @a.dubey @aksharma Please follow this and let me know if there still persist any issues

added 1 commit

e38521cd - Update CbmMuchDigitizeGem.cxx

@a.agarwal_AT_vecc.gov.in this will solve one problem, but there is one more bias ness. If (Spot Radius >> Underlying Pad size) then charge is distributed to only 2 boundary pads not on all the affected pads. I agree that presently spot radius for both GEM and RPC is lesser than pad size, however, we may correct that also in this MR.

I agree with this proposal. It may also be prudent to give a warning if spot radius exceeds the pad size.

@f.uhlig Could it be that something went wrong with the rights of Apar fork?

the format check job seems to claim being stuck because not Apptainer runners are free, but I see at least 2 being idle in the admin area
from what I remember it is not his first MR so all memberships should be set for is fork

I believe it is my fault here since I have created a new fork for committing this one change since the last one diverged from the upstream repository and I could not pull the latest changes. I was afraid that it may create some inconsistencies if the fork has diverged too much. Please guide me accordingly on how to correct it from my end.

I think you should then create new "branches", not new "forks".
Whenever you delete your fork and re-create it @f.uhlig needs to rerun a script to give it access to our runners

Divergence problems should be resolved with a git rebase upstream, in our workflow we never pull from the upstream-master.
We have a gitlab tutorial project but I realize now that it was not updated over the years to provide solutions to some often encountered problems by new users.
Probably the best current description of some of the issues with our workflow and their solutions is this presentation by @f.uhlig: https://indico.gsi.de/event/11269/contributions/47499/attachments/32808/42148/GitRebaseIssues.pdf (maybe there is a more recent version in which case Florian will correct me)

I am not aware of any newer presentation about merge conflicts, so the one linked by Pierre is okay. You can also have a look at

https://redmine.cbm.gsi.de/projects/cbmroot/wiki/GitIntroduction

where three presentations about git and our workflow are linked.

@a.agarwal_AT_vecc.gov.in,

after I have added your fork to the runners the code format check runs. Due to changes in our clang-format configuration there is now an error. Please rerun clang-format with the latests configuration.

To get the up to dat config please fetch from the upstream repository, rebase and push the changes to your branch.

git fetch upstream
git rebase upstream/master
git push <your_repo_name> <your_branch_name>

added 4 commits

e38521cd...64567da6 - 3 commits from branch computing:master
29a463ab - Merge branch cbmroot:master into master

Compare with previous version

added 1 commit

cc08d033 - Clang Format implemented along with special case of pad size being smaller than the spot radius

Compare with previous version

@v.singhal @a.dubey I have implemented the special case of pads being smaller than spot radius. Could you please check it?

added 7 commits

cc08d033...aa8e42c7 - 4 commits from branch computing:master
90ac2361 - To implement correct digitization on the side boundary pads for both GEM and...
b171b346 - Update CbmMuchDigitizeGem.cxx
68182f44 - Clang Format implemented along with special case of pad size being smaller than the spot radius

Compare with previous version