Tracy profiler integration

[divyaprakash-iitd]

Proposed Changes

Integrated the Tracy profiler into the SU2 codebase with Meson support. Added build options for enabling profiling, instrumented the function Predict_MLP in SU2_CFD/src/fluid/CDataDrivenFluid.cpp with Tracy macros for demonstration of performance monitoring, and updated the configuration summary for clarity. These changes allow real-time, low-overhead performance analysis via the Tracy GUI.
Details of these changes are documented in my blog post: https://dpcfd.com/posts/2025/07/gsoc-week-3/
Details of these changes are here: https://github.com/divyaprakash-iitd/su2code.github.io/blob/develop/_docs_v7/Tracy-Integration.md

Related Work

This PR does not resolve any open issues but contributes to profiling. This effort aligns with ongoing GSoC work.

PR Checklist

• I am submitting my contribution to the develop branch.
• My contribution generates no new compiler warnings (try with --warnlevel=3 when using meson).
• My contribution is commented and consistent with SU2 style (https://su2code.github.io/docs_v7/Style-Guide/).
• I used the pre-commit hook to prevent dirty commits and used pre-commit run --all to format old commits.
• I have added a test case that demonstrates my contribution, if necessary.
• I have updated appropriate documentation (Tutorials, Docs Page, config_template.cpp), if necessary.

[bigfooted]

Hi Nice to have this, can you also add your blog post to the tutorial page on su2code.github.io, maybe under Developer Docs?

[divyaprakash-iitd]

Hi Nice to have this, can you also add your blog post to the tutorial page on su2code.github.io, maybe under Developer Docs?

I have added a new file, Tracy-Integration.md, to the _docs_v7 directory in the develop branch of the su2code/su2code.github.io repository and submitted a pull request. Is this the correct location for new documentation?

[pcarruscag]

Does this only profile the functions you annotate? Do you still see them as fraction of total time even if you don't annotate the main function of the code?

To integrate this type of tools that require intrusive changes to be used (i.e. annotations) we need to wrap them.

Similar to what we do for AD, OpenMP, etc., if tracy is included then you define some macros for the functionality that we want to expose (e.g. ZoneScopedN) and you turn on the include of tracy (it should not be included explicitly in any other files).
Have a look at omp_structure.hpp and follow the same pattern.

[divyaprakash-iitd]

Does this only profile the functions you annotate? Do you still see them as fraction of total time even if you don't annotate the main function of the code?

To integrate this type of tools that require intrusive changes to be used (i.e. annotations) we need to wrap them.

Similar to what we do for AD, OpenMP, etc., if tracy is included then you define some macros for the functionality that we want to expose (e.g. ZoneScopedN) and you turn on the include of tracy (it should not be included explicitly in any other files). Have a look at omp_structure.hpp and follow the same pattern.

Yes, it profiles only the annotated functions, and the functions still appear as a fraction of the total time without annotating the main function.
Thank you for your suggestions. I have looked at "omp_structure.hpp" and implemented a similar "tracy_structure.hpp". I have added documentation on using it to a separate PR. I have verified it by testing on my system. Please let me know if I should make any changes.