Adding new analysis TRestTrackAlphaAnalysisProcess #13

juanangp · 2022-01-27T19:04:18Z

New analysis have been added to tracklib to analyze alpha tracks, which was developed for AlphaCAMM.
A macro has been added to display the analysis results.

Summary of latest changes as requested in this PR:

New TRestTrackViewerProcess for track visualization.
New drawing methods have been added to TRestTrackEvent
Renaming TRestTrackAlphaAnalysisProcess to TRestTrackLineAnalysisProcess
New generic class TRestTrackLinearizationProcess, which is meant for track linearization.
Adding new methods to TRestTrackReductionProcess and TRestTrackPathMinimizationProcess
Now the macro lies in a dedicated repository for AlphaCAMM.

…lpha tracks

jgalan · 2022-01-28T11:58:33Z

macros/REST_Track_PlotAlphaAna.C

+
+}
+
+TPad *DrawHits ( TRestDetectorHitsEvent *hitsEvent, const TVector3 &origin, const TVector3 &end, TVector3 &max, TVector3 &min, TVector3& nBins) {


It would be good that Drawing methods would be common inside TRestDetectorHitsEvent.

jgalan · 2022-01-28T12:00:12Z

macros/REST_Track_PlotAlphaAna.C

+
+}
+
+TPad *DrawPulses ( TRestRawSignalEvent *rawSignalEvent, TRestDetectorReadout *fReadout) {


Perhaps this could be implemented at TRestDetectorSignalEvent

The problem is that I need the readout info to distinguish between X and Y tracks and it is not straithforward to get it.

The hits at TRestDetectorSignalEvent know about the readout, and also are capable to identify if they are X, Y type.

These are TRestRawSignalEvents, I have already implemented a method to plot a vector of sIDs.

I thought some pulse drawing methods at the detector level were alreaqdy implemented by you at TRestDetectorReadoutEventViewer

jgalan · 2022-01-28T12:01:10Z

macros/REST_Track_PlotAlphaAna.C

+const int offset=10;//bins
+
+
+TPad *DrawTrack ( TRestTrackEvent *trackEvent, const TVector3 &origin, const TVector3 &end, const TVector3 &max, const TVector3 &min, const TVector3& nBins) {


Perhaps better to implement inside TRestTrackEvent

Here is difficult to get the histogram boundaries, so I pass several TVector3 for the boundaries

I understand, but anyway it could be implemented at TRestTrackEvent and the macro would just call to this method?

See for example SetBoundaries method at TRestDetectorHitsEvent. https://sultan.unizar.es/rest/TRestDetectorHitsEvent_8cxx_source.html

Of course, those methods could be even further promoted to a higher class, it would be good to have dedicated drawing classes for hits and for time signals that centralize that kind of staff.

jgalan · 2022-01-28T12:02:28Z

src/TRestTrackAlphaAnalysisProcess.cxx

+///
+///             TRestTrackAlphaAnalysisProcess.cxx
+///
+///_______________________________________________________________________________


Please, add the official headers. Add also some documentation, include figures if possible.

See for example https://sultan.unizar.es/rest/classTRestDetectorSignalToRawSignalProcess.html

jgalan · 2022-01-28T12:05:56Z

src/TRestTrackAlphaAnalysisProcess.cxx

+
+    debug<<"Track length "<<length<<" angle: "<<angle<<endl;
+
+    // A new value for each observable is added


Document observables in documentation

jgalan · 2022-01-28T12:10:00Z

src/TRestTrackAlphaAnalysisProcess.cxx

+
+//______________________________________________________________________________
+void TRestTrackAlphaAnalysisProcess::InitFromConfigFile() {
+  fTrackBalance = StringToDouble(GetParameter("trackBalance", "0.65"));


There is no need to implement this method. Simply remove completely InitFromConfigFile from TRestTrackAlphaAnalysisProcess.

Then, TRestEventProcess::InitFromConfigFile will be responsible to identify a fDummyVariable with the parameter given in the config file dummyVariable.

In the case of trackBalance you just need that a data member named fTrackBalance exists.

The declaratio at the header would look as:

/// A parameter to define the track balance ... bla bla bla Double_t fTrackBalance = 0.65;

Actually the methods LoadDefaultConfig(), LoadConfig(), TRestTrackAlphaAnalysisProcess(char* cfgfile) are not needed either.

jgalan · 2022-01-28T12:11:23Z

inc/TRestTrackAlphaAnalysisProcess.h

+
+   protected:
+    // add here the members of your event process
+


Methods to be documented at CXX.

jgalan · 2022-01-28T12:11:35Z

inc/TRestTrackAlphaAnalysisProcess.h

+///
+///             TRestTrackAlphaAnalysisProcess.h
+///
+///_______________________________________________________________________________


Use official headers

jgalan · 2022-01-28T12:13:53Z

This PR is somehow related with rest-for-physics/framework#31

Not sure how it is related to #31, perhaps you refer to the wrong PR?

…functions

jgalan · 2022-02-21T12:26:26Z

macros/REST_Track_PlotAlphaAna.C

+#include <TRestRawSignalEvent.h>
+
+#include "dirent.h"
+


This method should not be implemented at the level of tracklib. If REST is not compiled with detectorlib or rawlib there will be problems when this macro is being loaded in restRoot.

Indeed, you are right.

Do you prefer to move to general macros directory? I don't know what is the best strategy here.

The libraries design is to focus on independent development of libraries. So that a particular library keeps a minimum of dependencies with other libraries. I am sure it is possible to think a way to keep that strategy alive.

In the case this is not possible, and using rawlib routines inside the tracklib is a must (although I would prefer to find a way to avoid) then the code instantiating rawlib must be encapsulated using a compilation flag, that could be created for example at cmake/MacroRootDict.cmake at COMPILEDIR, and define a #ifdef RESTLIB_RAW, not sure if this already exist. @nkx?

However, I would prefer that such a possibility does not exist, the present structure is the result of an effort to organise the code project, and I believe keeping isolated developments at the libraries as they are is the best to avoid future chaos. I understand this requires an effort, but I am open to discuss about possible solutions for the present implementation.

Keep present that if you add your macro to the tracklib pipeline, where only track routines are tested, the execution will fail.

https://gitlab.cern.ch/rest-for-physics/tracklib/-/pipelines/3637513

At the rawlib there are already a few tests running that do not need other libraries, we should push for something similar at tracklib

https://gitlab.cern.ch/rest-for-physics/tracklib/-/pipelines/3637513

Adding it to the framework domain is also not desirable. The framework should know nothing about signal processing, physical track event reconstruction, detectors, etc. It should only implement basic analysis routines not connected to those domains. Such as fitting analysis tree observables, etc. This is discussed in the paper.

To add dependency we can just call:

set(deps detector geant4 track raw) COMPILELIB(deps)

Currently only connectorslib has dependency on others. Others are all independent. So it would be strange to make tracklib dependent on rawlib.

jgalan · 2022-02-21T12:27:22Z

macros/REST_Track_PlotAlphaAna.C

+ return fPad;
+
+}
+


Should probably need to be implemented at TRestTrackEvent.

jgalan · 2022-02-21T12:28:27Z

macros/REST_Track_PlotAlphaAna.C

+  endYZGr->Draw("LP");
+
+}
+


Should be implemented at TRestTools? There is no documentation, what it is doing this method? Perhaps there is already a similar method at TRestTools doing what is doing this one?

… is performed in a previous step

…p of unused classes

…e tsp problem BruteForce and NearestNeighbour. Clean up of unused classes.

jgalan · 2022-04-18T16:06:34Z

inc/TRestTrackLineAnalysisProcess.h

+
+#include "TRestEventProcess.h"
+
+//! A process to analyze alpha tracks


//! A process to identify and extract the track ends in linear approximation?

jgalan · 2022-04-18T16:07:08Z

inc/TRestTrackLineAnalysisProcess.h

+    void Initialize();
+
+   protected:
+    /// A parameter to define the track balance, otherwise the event is rejected


not clear, when the event is rejected?

jgalan · 2022-04-18T16:09:12Z

inc/TRestTrackLinearizationProcess.h

+        EndPrintProcess();
+    }
+
+    // This function performs the track linearization towards a given number of nodes


This description should be written in the implementation, at the cxx file.

jgalan · 2022-04-18T16:14:32Z

src/TRestTrackLineAnalysisProcess.cxx

+
+ClassImp(TRestTrackLineAnalysisProcess);
+
+//______________________________________________________________________________


Not the good formatting. Using REST_MakeProcess will produce the standard formatting.

jgalan · 2022-04-18T16:16:02Z

src/TRestTrackLineAnalysisProcess.cxx

+//////////////////////////////////////////////////////////////////////////
+/// The TRestTrackLineAnalysis process is meant to analyze lienar tracks,
+/// such as alpha tracks. It should retreive the information after performing
+/// TRestTrackLinearization process, for the time being only works when


What it happens if TRestTrackLinearizationProcess was not used earlier?

In fact, is not required to use TRestTrackLinearizationProcess before. It should work as soon as the reduced hits are ordered. I am going to change the description.

Ok. It is this process doing a linear fit to the hits? In that case the hit order would also be not relevant.

The hit order is required in the sense that it should follow the minimum path, this is guaranteed after performing TRestTrackLinearizationProcess . It can be also reached using TRestTrackPathMinimizationProcess after a TRestTrackReductionProcess.

However, at this stage the hits ordering doesn't require to have any preferred direction e.g. a hit ordering of 1->2->3->4->5 should give same solution as an inverted ordering 5->4->3->2->1

I see, we should probably introduce a mechanism that allows us to do something like ProcessRequired("TRestTrackPathMinimizationProcess") so that if the process does not exist earlier in the data chain it will be returning an error.

Another potential issue, perhaps @nkx111 sees an easy way

I created an issue about it rest-for-physics/framework#182

src/TRestTrackLineAnalysisProcess.cxx

jgalan · 2022-04-18T16:21:06Z

src/TRestTrackLineAnalysisProcess.cxx

+/// following the minimum path. It assumes that only one alpha track
+/// is present, using the parameter fTrackBalance to define the minimun energy
+/// fTrackBalance*totalEnergy of the total XZ or YZ energy to assume a single
+/// track event, if the condition is not fulfilled the event is rejected.


I think we should try to do not reject events. If it is not a good event, then we will be able to discriminate it later using filters at the analysisTree.

Ok, the parameted fTrackBalance has been removed, now we have 2 observables instead trackBalanceX and trackBalanceY

jgalan · 2022-04-18T16:31:56Z

src/TRestTrackLinearizationProcess.cxx

+//______________________________________________________________________________
+TRestEvent* TRestTrackLinearizationProcess::ProcessEvent(TRestEvent* evInput) {
+    fTrackEvent = (TRestTrackEvent*)evInput;
+    fOutTrackEvent->SetEventInfo(fTrackEvent);


This is not necessary anymore, event header transfer is implemented at:

void TRestEventProcess::BeginOfEventProcess(TRestEvent* inEv) {

SetEventInfo has been removed

jgalan · 2022-04-18T16:36:35Z

src/TRestTrackLinearizationProcess.cxx

+//////////////////////////////////////////////////////////////////////////
+/// The TRestTrackLinearization process is meant to analyze linear tracks,
+/// such as alpha tracks. It should retreive the information after performing
+/// TRestTrackLinearization process, not implemented for XYZ tracks.


GetHitsProjection was implemented time ago to reconstruct the profile of a physical track event along the track. The track could be a complex electron track event (no need to be linear). I understand this process is doing now something else, I could enter in the details of how this is being used here, but I dont see how this is required to perform the fitting to the raw hits.

The process producing a track profile could be probably named TRestTrackProfileProcess, generating a std::vector or a TGraph with N points where the hits energy have been projected.

Sorry, I don't understand this comment. Do you want to rename TRestTrackLinearizationProcess to TRestTrackProfileProcess?

Perhaps the naming of GetHitsProjection function is not adequate? I can rename the function. This function is actually performing the track linearization.

Or you want to split the process in two different processes one doing the linear fit or profile and another process doing the average of the closest hits? Also, I don't understand why do you want to store the results as an std::vector or TGraph since I believe is better to store as TRestVolumeHits

We should discuss this online

jgalan · 2022-04-18T16:39:54Z

src/TRestTrackPathMinimizationProcess.cxx

+
+// Return the index with the shortest path solving Travelling Salesman Problem (TSP) using
+// brute force, algorithm complexity is n!, the minimum path is guarantee
+//______________________________________________________________________________


This is not the standard format for method documentation

jgalan · 2022-04-18T16:46:26Z

src/TRestTrackViewerProcess.cxx

+///
+void TRestTrackViewerProcess::DrawOriginEnd(TPad* pad, std::vector<TGraph*>& origin,
+                                            std::vector<TGraph*>& end, std::vector<TLegend*>& leg) {
+    for (int i = 0; i < 2; i++) {


It should check if origin, end and leg got exactly 2-elements. I would allow to do not check this if the method were private and it is clear that the only case is that it will contain 2-elements. But the method was declared public.

jgalan · 2022-04-18T16:51:33Z

src/TRestTrackViewerProcess.cxx

+/// \brief Get origin and end of the track if trackLineAnalysis have
+/// been performed
+///
+void TRestTrackViewerProcess::GetOriginEnd(TRestAnalysisTree* anaTree, std::vector<TGraph*>& origin,


Why it receives a pointer to TRestAnalysisTree? The process will always have access to the analysis tree, i.e. using this->GetFullAnalysisTree() or this->GetAnalysisTree().

Perhaps this is a method to be implemented at TRestTrackEvent, or event at a new class TRestTrackPainter that implements statics methods, then TRestTrackEvent could inherit from TRestTrackPainter, the methods at TRestTrackPainter would get the pointer to the TRestTrackEvent, but I see it harder with TRestAnalysisTree.

Note that the function is declared static, so it need a TRestAnalysisTree passed to the function. I prefer to use static functions in this case because it allows me to use elsewhere.

I understand the benefit of using static functions, just that perhaps should be placed at a common class contextualizing it, such as TRestTrackPainter. For me, it makes sense to associate a GetOriginEnd to a TrackEvent, but not to the process.

Or perhaps a TRestTrackAnalysis that contains a static method GetOriginEnd implementing an algorithm that extracts origin/end from the track, but not from the analysis tree. I would do the other way around. I would use the method to fill the analysis tree inside the process implementation.

I agree with you that most of the static methods should be implemented in a dedicated class, perhaps in this case would be better to use a namespace.

I like the idea to have different namespace such as TRestTrackPainter and TRestTrackAnalysis. However, I think that this approach should be more generic:

TRestTrackPainter should implement all the track drawing methods.

TRestTrackAnalysis should implement all the track analysis methods.

We should probably use a similar schema for all the libraries by defining dedicated TRestXXXPainter and TRestXXXAnalysis namespaces in every single library.

However, this approach would require several changes in the code that cannot be addressed in this PR. I can give a hand with the migration, but it would require a lot of work. Let me know what do you think.

Yes, that sounds good. If someone is leading that, I will also give a hand with the migration.

For this PR I think we need to chat online about the real need to request analysisTree variables in that method.

I am working on that, TRestTrackViewerProcess can call a static function on TRestTrackLineAnalysisProcess to calculate the origin and the end of the track.

Later on we can migrate all the static functions to TRestTrackPainter and TRestTrackAnalysis, or do yo prefer to do in this PR just with few static functions mentioned before?

Yes, that could be done later.

Ok, I have created an issue about this topic

rest-for-physics/framework#183

jgalan · 2022-04-18T16:52:44Z

src/TRestTrackViewerProcess.cxx

+    std::vector<std::string> eName = {"endX", "endY", "endZ"};
+
+    for (int i = 0; i < 3; i++) {
+        std::string fName = "alphaTrackAna_" + oName[i];


alphaTrackAna_ is defined by the user at the RML, then the name could be anything else, isnt?

If this observable was extracted from TRestTrackAnalysisProcess one could perhaps retrieve the process name as follows:

fRunInfo->GetMetadataClass("TRestTrackAnalysisProcess")->GetName();

However, it might happen that there are two classes TRestTrackAnalysisProcess inside the data processing chain.

Not sure if there is a better way @nkx?

I can see that GetObservableValue is used somewhere else in a similar way.

I can think in some analysis processes that may use some variables from the analysis tree as input. So, I don't know what is the best solution here. As far as I understand the observables are always retreived from the rml.

Perhaps we should create an issue about this?

Yes, I dont think it is good to hardcode the process name, since the user might change that value. On top of that, as I said earlier, it might happen that exist two TRestRawSignalAnalysisProcess inside the data processing chain. Which of them TRestDetectorSingleChannelAnalysisProcess would use?

On the other hand, the process TRestDetectorSingleChannelAnalysisProcess uses a TRestDetectorSignalEvent, so I believe the max_amplitude, thr_integral and PeakAmplitudeIntegral maps could be calculated directly inside the process without the need to retrieve them from a previous analysis. Isn't?

Just created issue rest-for-physics/detectorlib#47

…nstead trackBalanceX/Y

…unctions to static

…de TRestTrackEvent and TRestTrack

…cess

src/TRestTrackLineAnalysisProcess.cxx

src/TRestTrackLinearizationProcess.cxx

jgalan · 2022-04-21T17:49:55Z

Please, before merging increase the library version, tag it and add the release notes.

Adding new class TRestTrackAlphaAnalysisProcess for the analysis of a…

2123773

…lpha tracks

juanangp requested review from jgalan, nkx111, lobis and DavidDiezIb January 27, 2022 19:04

jgalan reviewed Jan 28, 2022

View reviewed changes

juanangp mentioned this pull request Jan 29, 2022

Adding new method to draw signals in TRestRawSignalEvent rest-for-physics/rawlib#46

Merged

juanangp added 5 commits January 31, 2022 13:20

Addressing github comments: proper documentation, removal of un-used …

a2de692

…functions

Adding new DrawEvent method to TRestTrackEvent

bb934f0

Implementing novel Draw classes methods in REST_Track_PlotAlphaAna macro

fceb4e0

Changing DrawEvent method, now histogram boundaries are required

904362f

Implementing the posibility of opening multiple files

1dd21ff

jgalan reviewed Feb 21, 2022

View reviewed changes

macros/REST_Track_PlotAlphaAna.C Outdated

return fPad;

}

Copy link

Member

jgalan Feb 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably need to be implemented at TRestTrackEvent.

jgalan reviewed Feb 21, 2022

View reviewed changes

juanangp added 7 commits March 16, 2022 09:41

Renaming TRestTrackAlphaAnalysisProcess to TRestTrackLineAnalysisProcess

b390baa

Adding new class TRestTrackLinearizationProcess

4c1aeaa

New class RestTrackViewerProcess for visualization of track events

7efae54

Changes in TRestTrackLineAnalysisProcess because now the linarization…

a45e2f5

… is performed in a previous step

Implementing new function to DrawHits in TRestTrackEvent

383eacc

Adding kMeansClustering method to TRestTrackReductionProcess, clean u…

f58d2ff

…p of unused classes

Implementing new methods in TRestTrackPathMinimizationProcess to solv…

0c98781

…e tsp problem BruteForce and NearestNeighbour. Clean up of unused classes.

jgalan reviewed Apr 18, 2022

View reviewed changes

src/TRestTrackLineAnalysisProcess.cxx Outdated Show resolved Hide resolved

jgalan reviewed Apr 18, 2022

View reviewed changes

juanangp added 4 commits April 19, 2022 09:34

Addressing formating for documentation

31cb1e4

Removal of parameter fTrackBalance, two new observables are defined i…

62042c1

…nstead trackBalanceX/Y

Removal of track->SetEventInfo(), seems that is not needed anymore

0c60652

Adding check of the size of several vectors in static function

8992844

jgalan mentioned this pull request Apr 19, 2022

Avoid invoking hardcoded process names when accessing analysis tree observables rest-for-physics/detectorlib#47

Open

juanangp added 6 commits April 19, 2022 14:10

Removal of retrieval of observables from analysis tree, moving some f…

165b128

…unctions to static

Updating documentation

ec6cb70

Revomal of static functions, now all the methods are implemented insi…

3dd06ef

…de TRestTrackEvent and TRestTrack

Removal of unnecesary forward class declaration and ifndef CINT

2e62fb3

Now only low level tracks are processed in TRestTrackLinearizationPro…

1fbb250

…cess

Fixing validation code issue

eb225ec

jgalan reviewed Apr 21, 2022

View reviewed changes

src/TRestTrackLineAnalysisProcess.cxx Outdated Show resolved Hide resolved

jgalan approved these changes Apr 21, 2022

View reviewed changes

src/TRestTrackLinearizationProcess.cxx Outdated Show resolved Hide resolved

juanangp added 2 commits April 22, 2022 11:54

Addressing comments on PR

5484a4a

Increasing library version

9cf0fe3

juanangp merged commit 423ac0a into master Apr 26, 2022


		}

		TPad DrawHits ( TRestDetectorHitsEvent hitsEvent, const TVector3 &origin, const TVector3 &end, TVector3 &max, TVector3 &min, TVector3& nBins) {


		}

		TPad DrawPulses ( TRestRawSignalEvent rawSignalEvent, TRestDetectorReadout *fReadout) {

		const int offset=10;//bins


		TPad DrawTrack ( TRestTrackEvent trackEvent, const TVector3 &origin, const TVector3 &end, const TVector3 &max, const TVector3 &min, const TVector3& nBins) {


		debug<<"Track length "<<length<<" angle: "<<angle<<endl;

		// A new value for each observable is added


		#include "TRestEventProcess.h"

		//! A process to analyze alpha tracks


		ClassImp(TRestTrackLineAnalysisProcess);

		//______________________________________________________________________________

Adding new analysis TRestTrackAlphaAnalysisProcess #13

Adding new analysis TRestTrackAlphaAnalysisProcess #13

Conversation

juanangp commented Jan 27, 2022 • edited by pull-request-badge bot Loading

jgalan Jan 28, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgalan Jan 31, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgalan Jan 28, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgalan Jan 28, 2022 • edited Loading

Choose a reason for hiding this comment

jgalan Jan 28, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgalan commented Jan 28, 2022

Choose a reason for hiding this comment

juanangp Feb 21, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nkx111 Mar 2, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgalan Apr 19, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgalan Apr 18, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgalan Apr 18, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgalan Apr 18, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgalan Apr 18, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgalan commented Apr 21, 2022

juanangp commented Jan 27, 2022 •

edited by pull-request-badge bot

Loading

jgalan Jan 28, 2022 •

edited

Loading

jgalan Jan 31, 2022 •

edited

Loading

jgalan Jan 28, 2022 •

edited

Loading

jgalan Jan 28, 2022 •

edited

Loading

jgalan Jan 28, 2022 •

edited

Loading

juanangp Feb 21, 2022 •

edited

Loading

nkx111 Mar 2, 2022 •

edited

Loading

jgalan Apr 19, 2022 •

edited

Loading

jgalan Apr 18, 2022 •

edited

Loading

jgalan Apr 18, 2022 •

edited

Loading

jgalan Apr 18, 2022 •

edited

Loading

jgalan Apr 18, 2022 •

edited

Loading