Geometry Verification and Validation GUI in Qt · Google Summer of Code

Hey @Kanchan Borole This is the channel we will use to track your GSoC progress and discussions

Divyanshu Garg (May 01 2026 at 08:20):

Kanchan Borole (May 01 2026 at 08:42):

Divyanshu Garg (May 01 2026 at 09:17):

Awesome, since we are in the community bonding period, we can take it as an opportunity to get more familiar with what we are working with.
Here are our goals for the next 20 days:-

Divyanshu Garg (May 01 2026 at 09:33):

Divyanshu Garg (May 01 2026 at 09:37):

With that, I am Divyanshu, and we will be working together for the next few months to deal with the problem statements proposed. Excited about the good things we are gonna be achieving by the end of it.

Kanchan Borole (May 01 2026 at 10:16):

Thank you for the detailed overview! I will keep all of this in mind. I will start with setting up the development environment and going through the repository and documentation over the next few days. I will keep you updated on my progress regularly.

Kanchan Borole (May 02 2026 at 05:17):

Hi @Divyanshu Garg , I wanted to clarify my understanding before I proceed further.
My goal is to take the V&V features from the old isaacy13/arbalest fork (https://github.com/isaacy13/arbalest) and bring them into the latest official BRL-CAD/arbalest codebase. The old fork has the V&V functionality but uses Qt5. The latest arbalest uses Qt6 so my plan is to work on the latest BRL-CAD/arbalest and port the V&V features there using Qt6.
To set this up I need help with two things:

Divyanshu Garg (May 02 2026 at 07:25):

Divyanshu Garg (May 02 2026 at 07:31):

Wait a second, my bad, i misread it, If the latest is in QT6 ofcourse we do that one, Based on the last update i see it mentions Qt6.4.2

Divyanshu Garg (May 02 2026 at 07:32):

Divyanshu Garg (May 02 2026 at 07:36):

Kanchan Borole (May 02 2026 at 07:39):

Divyanshu Garg (May 02 2026 at 07:51):

Setting up BRLCAD MOOSE shouldn't be different since it follows standard/similar procedures we have in textbook C++ projects. One of the easiest ways to do that is to search and learn how we usually run similar apps on windows and it should be following the same procedure.

But, also noticed that you mentioned BRLCAD_MOOSE not BRLCAD/MOOSE a variable which is mentioned in the arbalest repository cmakelist. In that particular query
it should work with something like this cmake .. -DBRLCAD_MOOSE_DIR=C:\moose-install, basically resolving the directory as required.

Kanchan Borole (May 03 2026 at 05:01):

Hi @Divyanshu Garg , Update on my environment setup progress:
Successfully done:
Qt 6.11.0 installed
BRL-CAD 7.32.2 installed
Latest BRL-CAD/arbalest cloned
Issue I am facing:
I ran cmake on latest arbalest with this command:

cmake .. -DBRLCAD_BASE_DIR="C:\brlcad\BRL-CAD 7.32.2" -DQt6_DIR="C:\Qt\6.11.0\msvc2022_64\lib\cmake\Qt6" -DCMAKE_POLICY_VERSION_MINIMUM=3.5

Getting this error: CMake Error in CMakeLists.txt:
Found relative path while evaluating include directories of "ZERO_CHECK":
"BRLCAD_MOOSE_INCLUDE_DIR-NOTFOUND"

I also tried your suggestion of using -DBRLCAD_MOOSE_DIR flag but there is no MOOSE directory in my BRL-CAD 7.32.2 installation. I also tried building BRL-CAD from source earlier but was getting png/asm compilation errors and the build failed.
Could you please tell me which BRL-CAD version includes MOOSE or where I can get it for Windows?

Divyanshu Garg (May 03 2026 at 07:30):

Divyanshu Garg (May 03 2026 at 07:51):

Kanchan Borole (May 03 2026 at 15:08):

Following your suggestion, I cloned MOOSE from https://github.com/BRL-CAD/MOOSE and tried building it with installed BRL-CAD 7.32.2 but got this error:
Could not find BRL-CAD
So I tried building BRL-CAD from source again. Disabled GDAL and iwidgets as they were failing but still getting:
Unable to successfully build bext dependency repository
I am on Windows. Should I use WSL to build BRL-CAD from source? Please guide me on the best approach to move forward.

Daniel Rossberg (May 03 2026 at 16:20):

@Kanchan Borole, version 7.32.2 is 5 years old and not suited as base for actual development. You need to compile the libraries and programs from source, to be able to include their latest changes in your development.

In general, MS Visual Studio is the recommended build environment for Windows, i.e. it should work. Most of the development was however done with MSVS 2022, and there are apparently some issues with MSVS 2026. I.e., you could try Visual Studio 2022.

Kanchan Borole (May 04 2026 at 08:52):

Thank you @Daniel Rossberg for the detailed guidance and the compilation guide! I will follow the steps at https://drossberg.github.io/BRL-CAD/compiling.html and try again building BRL-CAD from source using Visual Studio 2022. Will update you on the progress!

Divyanshu Garg (May 04 2026 at 16:36):

Himanshu (May 04 2026 at 19:25):

Hi @Kanchan Borole , going forward I will also be part of this project in terms of mentoring. I am little bit late to join :sweat_smile:.

Kanchan Borole (May 05 2026 at 09:08):

Hi, Progress update on the environment setup: I tried setting up on Windows but kept facing dependency build errors and could not complete the build successfully. Anyhow I then arranged a Linux system (Ubuntu 24.04.3) and happy to share that I have successfully built BRL-CAD 7.43.0 from source and installed it! Now proceeding to build MOOSE and will update on the progress soon.

Kanchan Borole (May 05 2026 at 09:08):

Hi @Himanshu , looking forward to working with you and learning from you throughout this project!

Divyanshu Garg (May 05 2026 at 09:30):

That sounds amazing @Kanchan Borole,
Things are mostly much easier to deal with on Linux compared to Windows

Divyanshu Garg (May 05 2026 at 09:30):

Daniel Rossberg (May 05 2026 at 10:33):

@Kanchan Borole, in the MOOSE CMake configuration, you should set BRLCAD_STATIC_LINK to OFF and MODULE_COMMANDPROMPT to ON. This is necessary to build and run arbalaest later on.

Kanchan Borole (May 05 2026 at 13:58):

Sean (May 05 2026 at 16:50):

the V&V gui while started with arbalest, it kind of ended up like an application fork. part of this effort is not just updating to the latest arbalest/moose code, but then also separating the domain-specific V&V logic that was coded up. the app logic should probably be a plugin or set of plugins or some sort of overlay that works with and/or extends arbalest/moose's api with it's app-specific behavior.

Kanchan Borole (May 06 2026 at 09:55):

Hi, I was able to successfully built MOOSE (all tests passed). However, I’m currently facing an issue while building Arbalest.
The build reaches 100%, but it fails at the linking stage with multiple undefined reference errors related to BRL-CAD functions (like bu_malloc, rt_shootray, etc.) and also BRLCAD::CommandString. There is also a warning about librt.so.20 not being found, which seems to be coming from /usr/local/lib/libbrlcad.so.

My current setup is:
BRL-CAD installed at: /usr/brlcad/dev-7.43.0
MOOSE installed at: /usr/local

And I configured Arbalest using:
cmake .. -DBRLCAD_BASE_DIR=/usr/brlcad/dev-7.43.0 -DBRLCAD_MOOSE_DIR=/usr/local
It looks like there might be a linking mismatch or conflicting BRL-CAD libraries being picked up.
Could you please guide me on how to resolve this linking issue?

Divyanshu Garg (May 06 2026 at 09:56):

Kanchan Borole (May 06 2026 at 10:03):

Hi @Sean , Thanks for the clarification — that helps a lot.
I’ll keep this in mind and focus on how to modularize the existing V&V logic accordingly.

Divyanshu Garg (May 06 2026 at 10:09):

@Kanchan Borole can you please check if you have an older installations?
I just checked the codebase the 2 methods you mentioned are there in version 7.43.0

Kanchan Borole (May 06 2026 at 10:24):

Thanks — that makes sense. I wasn’t able to see any older installation in /usr/local on my side, but I may be missing something. I’ll do a clean rebuild and double-check the linking to ensure it’s using the correct BRL-CAD version.

Daniel Rossberg (May 06 2026 at 10:31):

BRLCAD_MOOSE_DIR has to point to the directory, where you installed MOOSE. I.e., what's your directory layout?

Kanchan Borole (May 06 2026 at 10:35):

Here is my current setup:
BRL-CAD source dir: ~/gsoc/src/brlcad
BRL-CAD install dir: /usr/brlcad/dev-7.43.0
MOOSE source dir: ~/gsoc/src/moose
MOOSE install dir: /usr/local
Please let me know if this looks correct or if I should change anything.

Daniel Rossberg (May 06 2026 at 10:48):

OK, first, I recommend to install the stuff somewhere at ~/gsoc, because you do not need to become root for installation then. E.g., ~/gsoc/inst/brlcad and ~/gsoc/inst/moose.

You can change the installation paths by changing CMAKE_INSTALL_PREFIX with the CMake gui, for example.

Daniel Rossberg (May 06 2026 at 10:52):

Then, cmake ~/gsoc/src/arbalest -DCMAKE_BUILD_TYPE=Debug -DBRLCAD_MOOSE_DIR=~/gsoc/inst/moose should create you a working build set-up for arbalest.

starseeker (May 06 2026 at 11:29):

Probably Arbalest will need some updates to build against latest main - I have a branch with work like that for MOOSE, but I haven't checked Arbalest yet (juggling a lot of balls right now)

Daniel Rossberg (May 06 2026 at 12:12):

There were no changes to arbalest neccessary. The MOOSE API is unchanged :grinning_face_with_smiling_eyes:

Divyanshu Garg (May 06 2026 at 15:28):

Hey @Kanchan Borole
I went ahead and started messing around the installation, and here is
ISSUE.md
a MD file which might help you with the issues you are facing

Daniel Rossberg (May 06 2026 at 19:20):

Hmm, setting BRLCAD_VERSION shouldn't be necessary on Linux. It should be set by calling brlcad-config. Unfortunately, this script doesn't work on Windows.

In general, when configuring the MOOSE or arbalest build, read the output carefully. The error messages should contain a hint how to resolve them.

In addition, the brlcad installation binary directory should be included in the PATH environment variable of your command shell. This makes it easier to call the BRL-CAD programs (mged, archer, and some more of the 300+(?) command line tools).

starseeker (May 07 2026 at 00:10):

I'm trying to work on a modern find_package Config.cmake solution that will make things a little easier, fwiw. It's not done yet - I'm still trying to figure out shared vs. static issues properly - but if I can get it right we can hopefully reduce brlcad-config to a small program that provides the correct inputs so a CMake build will find our Config.cmake file and take it from there (and make it work on Windows while we're at it)

Daniel Rossberg (May 07 2026 at 14:35):

What came into my mind too: As developers, we should set -DCMAKE_BUILD_TYPE=Debug. We may need to debug our stuff :wink:

Kanchan Borole (May 08 2026 at 12:09):

Hi, I have successfully built and run Arbalest. Really grateful for all the guidance and support.
I have also set up a tracking repository where I am maintaining my architecture understanding, daily logs, and setup notes: https://github.com/KanchanBorole/gsoc-2026-brlcad-vv
Next I am planning to:

Divyanshu Garg (May 08 2026 at 12:12):

That sounds amazing. It's great that you are also documenting the progress and your efforts.
On that note, you can also add this documentation information to the official repositories and send a PR, so that someone working in the future can set up the builds more easily.

Kanchan Borole (May 08 2026 at 12:18):

Thank you! That makes sense — I’ll clean up the setup notes properly and plan to contribute them back to the official repositories through PRs so the setup process becomes easier for future contributors as well.
And yes, I do use AI tools occasionally during development, mainly for: understanding unfamiliar codebases, debugging build/configuration issues, exploring documentation faster, improving development workflow and learning. But I make sure to understand the changes and debugging process myself while working through the project.

Divyanshu Garg (May 08 2026 at 12:24):

Sweet, before we do the dev work. We support the usage of AI, but that must happen responsibly. AI-based code is acceptable as long as the contributor knows exactly what it does and ensures its quality and standards meet the existing code standards. In Short, avoid sending whatever AI implements. I am pretty certain that you already know and understand this, but still mentioning it anyway. Thanks for understanding. :grinning_face_with_smiling_eyes:

Himanshu (May 09 2026 at 14:18):

Himanshu (May 09 2026 at 14:19):

starseeker (May 09 2026 at 19:25):

Kanchan Borole (May 11 2026 at 09:06):

Hi, I have been going through the isaacy13 fork codebase to understand the V&V implementation. I noticed that the V&V logic is spread across a few files — VerificationValidationWidget, VerificationValidation, and VerificationValidationParser.
To understand how to separate it, I tried creating a plugins/vv folder structure inside the latest arbalest src and include directories and started configuring it. While trying to get it working, I ran into several API mismatches — functions like getDocuments(), setStatusBarMessage(), popup() and others that exist in the old fork but not in the latest arbalest.
As the V&V logic should be a plugin or overlay that extends Arbalest/MOOSE API. What would be the recommended way to port the existing V&V code from the old fork into the latest arbalest as a plugin — keeping the existing V&V logic but adapting it to work with the latest APIs? Also how should the plugin connect and integrate with the main Arbalest application?

Sean (May 12 2026 at 20:34):

Those are tough questions @Kanchan Borole ... I can tell you how I'd likely approach it, but there are lots of possible ways to proceed.

You could check out a copy of arbalest from before the v&v changes, for example, so you can diff that against the latest arbalest, to understand what all has changed. That kind of analysis would be great for AI to do for you since it's more about understanding. Then you'd hopefully have a better sense how to re-apply the changes on the latest code.

Alternatively if the old commits are nice and concise, you could simply replay each one in order, adapting code as you go in a smaller local context to achieve a similar end result. That approach would be more about learning the current arbalest interface and making decisions as you go on an appropriate path forward, whether to extend arbalest to get the same result or moose, or some other approach.

You could also go "cold-turkey" and just compile up the old V&V fork, itemize all the end-user features you see in great detail, then (re-)implement them in the latest arbalest cleanly without much regard to how they were implemented originally. The code becomes a last resort consult, an assumption that it's easier to write new with clean design in mind than it is to read old and port. Merits to both.

Personally, I'd compile the old up and get it working. That's critical to understanding the code. Then, compile the new, and seeing on a file-by-file basis what is needed to get that functionality working. Might even try refactoring the old simultaneously while refactoring the new, until it can just work in both.

Daniel Rossberg (May 13 2026 at 07:18):

Hi @Kanchan Borole, it looks like you found almost all relevant files with the V&V logic. Some hints:

Kanchan Borole (May 13 2026 at 12:10):

Hi @Sean and @Daniel Rossberg , thanks a lot for the guidance and suggestions. I’ve been trying to understand both the old V&V fork and the latest Arbalest structure based on your advice.

As an experiment, I tried integrating the VV-related code into the latest Arbalest through a separate modular plugins/vv style structure instead of directly mixing things into the core application. For now, I exposed it through a dockable VV panel just to test the integration approach with the latest Arbalest/Qt6 setup.

I mainly wanted to ask whether this kind of direction is roughly what you had in mind, and also whether the VV functionality should eventually live primarily as a dock widget, a dedicated menu/toolbar integration, or some other extension mechanism inside Arbalest.

Daniel Rossberg (May 14 2026 at 13:47):

Your prototype looks good to me. However, I'm not an expert for the V&V stuff. I keep mainly an eye on a clean implementation. E.g. that no new dependencies are introduced. I try to answer the question "How to do it with MOOSE?"

Sean (May 14 2026 at 20:29):

@Kanchan Borole integrating as a separate modular plugin is absolutely in the right direction. The difficulty is going to be whether adaptations to arbalest are needed to achieve the same end results as the old GUI. The old GUI changed several aspects of the GUI such as overriding the menu with some changes/additions, overriding the button bar to add at least one "compile/stop" button, and adding a new Qt widget to the bottom with a list view that interacted seamlessly (e.g., selecting a warning, the geometry involved was indicated). I believe there was also a window you could open on warnings/issues that gave even more info in a new window.

So I'd say tackle those features one at a time and see where you get. You clearly added a plugin that added a Qt widget context. Maybe try to make it automatically display across the bottom with a list view inside it -- not something the user has to do. Don't know if that'd require arbalest changes to even do that sort of GUI mod on plugin load, but it's a start. Then maybe try to do the same to mod the menu and add a button.

Kanchan Borole (May 17 2026 at 09:12):

I’ve continued working on reconstructing the old VV workflow/features on top of the latest Arbalest codebase while trying to keep the implementation modular and lightweight for now.

I’ve attached a short demo video of the current state. Before moving deeper into the actual geometry validation/overlap logic and MOOSE/MGED-style validation integration, I wanted to check whether this direction and level of Arbalest-side integration aligns with migration/reconstruction work.
Verification&Validation1.webm

Sean (May 18 2026 at 15:08):

@Kanchan Borole have you successfully compiled and run the old v&v gui? If not, you definitely should get it working just so you have baseline comparison on hand for UI/UX. there as a lot of time, thought, and effort put into what it did and how it presented it that would not be efficient to discard.

Kanchan Borole (May 20 2026 at 11:22):

I’ve made progress on rebuilding the VV UI/workflow in the latest Arbalest codebase and wanted to check whether the current direction/workflow looks aligned with the expected VV behavior from the older implementation, or if there are areas that should be improved/refined before I continue further.
I’d appreciate guidance on the recommended next steps from here.
Verification & Validation 2.webm

Kanchan Borole (May 24 2026 at 10:53):

Hi, just following up - I wanted to ask what the recommended next focus area should be from here, and whether there are any areas in the current workflow/UI that should be adjusted or improved before moving further.
Also, would it be appropriate to start preparing/opening an initial PR for the current UI integration and workflow progress, or should I continue refining locally first?

Divyanshu Garg (May 24 2026 at 11:10):

Hey @Kanchan Borole do you feel that the work done as of now is ready for the first draft? If yes, you may send a PR
Also, have you added the issues on GitHub? That would help everyone to track what part of the GSoC project is done, and also find the linked code

Kanchan Borole (May 24 2026 at 11:39):

Thanks! I’ll start preparing the first draft PR.
Regarding the GitHub issues — should I create them directly in the official arbalest repository for tracking the different V&V tasks/features (UI integration, grouped workflow, exports, backend/result handling, etc.), or were you referring to a separate project board/tracking setup?

Divyanshu Garg (May 24 2026 at 11:40):

Kanchan Borole (May 25 2026 at 05:27):

Before preparing the PR, I wanted to confirm whether my current implementation direction is aligned with the intended architecture.
I added the V&V UI components under src/plugins/vv/ui/ (VVWidget, VVDockWidget, VVIssueDialog, VVTestSelectionDialog), updated the relevant CMakeLists.txt, and integrated them through MainWindow.

In MainWindow.h I added vvDockable, vvWidget, vvTimer, vvValidationQueue, vvRunning, vvCurrentIndex, vvTests, vvSuites, and the methods startVVValidation(), processVVValidation(), and stopVVValidation().

In MainWindow.cpp I added the V&V menu (Run Validation, Create/Remove Test, Create/Remove Suite, TXT/CSV/JSON export), toolbar actions (Run V&V, Stop), dock widget registration in prepareDockables(), validation workflow logic, report export functionality, and signal/slot connections for geometry selection and issue navigation.

Is this integration approach acceptable, or would prefer these menu registrations, toolbar actions, dock widget setup, and validation workflow to be moved into a dedicated plugin structure under src/plugins/vv/ instead? Also, is src/plugins/vv/ the appropriate location for this functionality, or would you recommend a different folder structure?

Himanshu (May 25 2026 at 17:40):

You can always draft the PR when it's in dev state. So no issues sending a PR. It can always be improved with newer commits.

Btw if I pick an example: vvDockableso this inherits Dockable that exist in Dockable.h or you did class vvDockable: public QDockWidget?

Himanshu (May 25 2026 at 17:42):

Kanchan Borole (May 26 2026 at 06:03):

Thanks! I’ve now opened the draft PR for early architecture/workflow review:
https://github.com/BRL-CAD/arbalest/pull/76
Currently VVDockWidget is implemented as class VVDockWidget : public QDockWidget, and the current V&V UI components are organized under src/plugins/vv/ui/. I’ll continue refining the structure further based on review feedback.

Kanchan Borole (May 28 2026 at 05:11):

While waiting for further UI/workflow review, I was planning to continue with the V&V result/report handling side (result structures, report generation/export organization, validation result management) since those seem relatively independent from the final UI/plugin arrangement.
Does that sound like a reasonable next step to proceed with meanwhile, or would you recommend a different next direction at this stage?

Divyanshu Garg (May 28 2026 at 15:08):

Kanchan Borole (May 28 2026 at 15:27):

Himanshu (May 29 2026 at 12:46):

I will review this weekend. Just yesterday only, I built arbalest. :sweat_smile:

Himanshu (May 31 2026 at 07:33):

@Kanchan Borole I tried to apply your patch but got errors while building arbalest. One example from your patch is:

bool maybeSave(int documentId, bool *cancelvoid prepareUi();
                   void loadTheme();
                   void setIcons();
                   void prepareDockables();
                   = nullptr);

Himanshu (May 31 2026 at 07:34):

Himanshu (May 31 2026 at 07:35):

Kanchan Borole (May 31 2026 at 08:28):

@Himanshu Thanks for checking. I found the issue in MainWindow.h, fixed it, rebuilt Arbalest locally, and updated the PR.

Himanshu (May 31 2026 at 21:02):

Himanshu (May 31 2026 at 21:05):

I saw timer-based validation is added for current checks. May be unnecessary for the current checks?? I am not sure on this. Maybe @Daniel Rossberg can help here.

Himanshu (May 31 2026 at 21:06):

Running one validation per second introduces unnecessary delay and complexity, I think. The current validations are lightweight string checks (empty names, duplicate names, spaces, temporary names) as for now I think no issues unless future validation steps are expected to be computationally expensive, consider processing the entire validation queue immediately or documenting the reason for the timer-based approach.

Kanchan Borole (Jun 03 2026 at 05:58):

I originally kept the timer because I was thinking ahead to future validations such as overlap/volume related checks, which may be more expensive than the current string-based checks. I would be interested to know whether an incremental approach still makes sense for the longer-term V&V direction.

Himanshu (Jun 03 2026 at 19:22):

Kanchan Borole (Jun 04 2026 at 05:49):

@Himanshu I have tried to fix these bugs. Could you please check if the changes look correct?

Daniel Rossberg (Jun 04 2026 at 15:05):

I didn't follow the discussion here. Was this a requirement? Well, I'm not against it. Have it as an option?

Daniel Rossberg (Jun 04 2026 at 15:34):

I think that PR #76 should be prepared for merging. I.e., bugs and missing features from Isaac's version should be ignored for now. Generally, the PR looks good. @Kanchan Borole, you should check line by line that the merge doesn't revert any change made in main arbalest meanwhile. Looking at https://github.com/BRL-CAD/arbalest/pull/76/changes I see a lot of such changes, mainly stylistic. It's bad habit to ignore changes made by others. I.e., to repeat it, check line by line for unintended reverts and remove them from your PR.

Kanchan Borole (Jun 05 2026 at 08:46):

Thanks for pointing this out. Some of the formatting changes were introduced unintentionally while I was working on it. I've tried to revert those changes and will keep this in mind going forward. Could you please check if the remaining changes look correct now?

Himanshu (Jun 06 2026 at 05:18):

I will look into the PR on Monday. Currently I'm outside and laptop isn't with me to review PR.

Daniel Rossberg (Jun 06 2026 at 14:58):

@Kanchan Borole, in https://github.com/BRL-CAD/arbalest/pull/76/changes, some files have a :no_entry: sign at their end. This means that they don't end with a newline. You should add it as this is considered as better style.

Daniel Rossberg (Jun 06 2026 at 15:09):

@Himanshu, if you agree, I can merge the pull requests (maybe, after the newlines were added). It may be not perfect, but it would be good to create a savepoint here.

Himanshu (Jun 08 2026 at 14:32):

Daniel Rossberg (Jun 08 2026 at 17:45):

Kanchan Borole (Jun 09 2026 at 05:33):

I was looking through the earlier discussion about the V&V logic, especially the part where the MGED-based execution would eventually need to be replaced using MOOSE/CommandString.
Before I start working on the next task, could you recommend what would be the best area to focus on next? I was considering the result/report handling side, but I wasn't sure whether it would be better to work on the execution/MOOSE side first or if there are other higher-priority V&V tasks that I should focus on at this stage.

Himanshu (Jun 10 2026 at 20:23):

I think to start with geometry verfication and validation logic and adding it in arbalest. Is it by using MOOSE/CommandString? Then go ahead.

Kanchan Borole (Jun 11 2026 at 14:11):

Currently I am investigating how to implement the actual verification and validation logic. I reviewed the existing Arbalest codebase, including the object tree traversal and BRL-CAD combination handling, to understand how geometry hierarchies are represented.

For the VV checks (such as Duplicate ID Check, No Nested Regions, and Overlap detection), I am trying to determine the intended approach. Should these checks be implemented primarily through MOOSE/CommandString functionality, or should they operate directly on the BRL-CAD database structures exposed within Arbalest?

I would also appreciate any guidance on whether there are existing GQA/VV workflows, commands, or MOOSE capabilities that I should build upon rather than implementing everything from scratch.

Daniel Rossberg (Jun 11 2026 at 18:53):

Kanchan Borole (Jun 14 2026 at 12:12):

I have tried to implement the MOOSE CommandString integration for the V&V plugin and raised a draft PR for review. I am not sure if the approach is correct, could you please review it. The gqa based tests cause arbalest to freeze during execution so I have skipped them for now.
PR Link - https://github.com/BRL-CAD/arbalest/pull/77

Daniel Rossberg (Jun 14 2026 at 17:35):

Daniel Rossberg (Jun 14 2026 at 17:38):

The issue with gqa could be caused by the different working directory or path to the executable, i.e., by arbalest not being in the brlcad bin directory.

Kanchan Borole (Jun 15 2026 at 08:45):

I have verified that the tests are being triggered correctly and I am seeing the expected output format in the console. However, due to the architecture migration, I am not entirely sure whether the behavior and results fully match with the previous implementation. It would be really helpful if you could check on your end and let me know if I'm missing anything in the logic, I'll make changes accordingly.

I tried setting the absolute path to the gqa executable to ensure it's found correctly, but Arbalest still becomes unresponsive during the test execution. I think this is because the execution is blocking the main UI thread. What do you think? Could you please guide me on the best approach to handle these long-running commands in Arbalest?

Daniel Rossberg (Jun 15 2026 at 17:52):

Kanchan Borole (Jun 16 2026 at 11:06):

I've curated a few geometries to test. These files contain specific issues like missing nested regions, material/LOS properties, and solids outside of regions. I have attached these files here. Additionally, I’ve been testing the plugin against existing BRL-CAD datasets like shipping_container.g and havoc.g. To be honest, I am currently unsure if the errors being flagged in these files are expected behavior or actual bugs.

Daniel Rossberg (Jun 17 2026 at 08:23):

Daniel Rossberg (Jun 17 2026 at 17:38):

Which are the gqa based tests? I run all tests on havoc.g. These are the results:

[INFO] Starting validation...
[PASSED] No mis-matched duplicate IDs
[ERROR] Duplicate ID check: sun/R
[PASSED] No matrices
[ERROR] Valid title: BRL-GSI Paris Air Show Soviet HAVOC Helicopter
[SKIP] Duplicate Geometry Names
[SKIP] No null region
[SKIP] Overlaps cleared to gridsize with tolerance
[PASSED] No nested regions
[PASSED] No empty combos
[PASSED] No solids outside of regions
[PASSED] All BoTs are volume mode (should return nothing)
[PASSED] No BoTs are left hand orientation
[PASSED] All regions have material
[PASSED] All regions have LOS
Checked object: sun
[PASSED] No mis-matched duplicate IDs
[ERROR] Duplicate ID check: havoc/
[PASSED] No matrices
[ERROR] Valid title: BRL-GSI Paris Air Show Soviet HAVOC Helicopter
[SKIP] Duplicate Geometry Names
[SKIP] No null region
[SKIP] Overlaps cleared to gridsize with tolerance
[PASSED] No nested regions
[PASSED] No empty combos
[PASSED] No solids outside of regions
[PASSED] All BoTs are volume mode (should return nothing)
[PASSED] No BoTs are left hand orientation
[PASSED] All regions have material
[PASSED] All regions have LOS
Checked object: havoc
[SKIP] No mis-matched duplicate IDs
[SKIP] Duplicate ID check
[SKIP] No matrices
[SKIP] Valid title
[SKIP] Duplicate Geometry Names
[SKIP] No null region
[SKIP] Overlaps cleared to gridsize with tolerance
[SKIP] No nested regions
[SKIP] No empty combos
[SKIP] No solids outside of regions
[SKIP] All BoTs are volume mode (should return nothing)
[SKIP] No BoTs are left hand orientation
[SKIP] All regions have material
[SKIP] All regions have LOS
Checked object: _GLOBAL
[PASSED] No mis-matched duplicate IDs
[ERROR] Duplicate ID check: BRL-GSI_EFFORT/
[PASSED] No matrices
[ERROR] Valid title: BRL-GSI Paris Air Show Soviet HAVOC Helicopter
[SKIP] Duplicate Geometry Names
[SKIP] No null region
[SKIP] Overlaps cleared to gridsize with tolerance
[PASSED] No nested regions
[PASSED] No empty combos
[PASSED] No solids outside of regions
[PASSED] All BoTs are volume mode (should return nothing)
[PASSED] No BoTs are left hand orientation
[PASSED] All regions have material
[PASSED] All regions have LOS
Checked object: BRL-GSI_EFFORT
[INFO] Validation Completed Successfully.

Daniel Rossberg (Jun 17 2026 at 17:39):

Daniel Rossberg (Jun 17 2026 at 17:41):

Kanchan Borole (Jun 18 2026 at 11:39):

Thanks for the feedback @Daniel Rossberg
Regarding the skipped tests, the GQA-based ones (overlaps and null regions) were causing the plugin to freeze, so I've commented them out in VVBackendTest.cpp and skipped them for now. The duplicate geometry name check is also still in progress, which is why it is currently skipped.
As for the errors in havoc.g, I am currently unsure if these are expected behaviors or actual bugs.

Daniel Rossberg (Jun 18 2026 at 19:23):

Okay, the good news first: gqa seems to work correctly. The small grid size of 4mm can just lead to long runtimes.

Daniel Rossberg (Jun 18 2026 at 19:30):

You should check, why some tests fail, which shouldn't. E.g., the "Valid title" for havoc.g. This works.

Daniel Rossberg (Jun 18 2026 at 19:32):

BTW, Isaac distinguishes between ObjectName and ObjectPath. It looks like you do not.

Kanchan Borole (Jun 19 2026 at 12:58):

Thanks for the feedback. I'll investigate the failing tests and the ObjectName/ObjectPath distinction. I'm away from my laptop this weekend due to some urgent work, but I'll keep an eye on the chat and continue working on this as soon as I'm back.

Kanchan Borole (Jun 23 2026 at 11:52):

I have revisited the logic to ensure a clear distinction between ObjectName and ObjectPath by passing the full path (resolvedPath) to all backend commands. I’ve tested this with havoc.g, and the logs now show the validator explicitly checking the full paths (e.g., [CHECKING] /havoc/...). Could you please take a look at the commit when you have a moment? I would like to confirm whether my understanding and implementation of ObjectPath is correct.

Daniel Rossberg (Jun 24 2026 at 17:55):

Looking at Isaac's version, I see "$OBJECT" with Arg::Type::ObjectName and "/$OBJECT" with Arg::Type::ObjectPath. In your version, there is resolvedPath only. Why? (Maybe, there is a good reason.)

Daniel Rossberg (Jun 24 2026 at 17:56):

Kanchan Borole (Jun 25 2026 at 08:23):

I initially used resolvedPath to verify the overall logic and ensure that the assembly could be loaded correctly. It was mainly a quick way to validate the workflow. I understand that keeping the distinction between Arg::Type::ObjectName and Arg::Type::ObjectPath is the proper approach, and I am prepared to refactor the code accordingly.

Regarding the command change, I tested both lc and ls using the Arbalest command window. Initially, I thought ls would be useful because it displays all database contents, but after testing, I found that it produces much more output than necessary, whereas lc is more suitable for inspecting specific parts. Therefore, I plan to use lc in the final implementation.

Could you please let me know whether the overall logic seems reasonable, and whether I should proceed with refactoring the implementation to match Isaac's approach?

Daniel Rossberg (Jun 25 2026 at 17:34):

Well, your general approach looks reasonable. I just wonder why you changed things.

Stream: Google Summer of Code

Topic: Geometry Verification and Validation GUI in Qt

Divyanshu Garg (May 01 2026 at 08:20):

Divyanshu Garg (May 01 2026 at 08:20):

Kanchan Borole (May 01 2026 at 08:42):

Divyanshu Garg (May 01 2026 at 09:17):

Divyanshu Garg (May 01 2026 at 09:33):

Divyanshu Garg (May 01 2026 at 09:37):

Kanchan Borole (May 01 2026 at 10:16):

Kanchan Borole (May 02 2026 at 05:17):

Divyanshu Garg (May 02 2026 at 07:25):

Divyanshu Garg (May 02 2026 at 07:31):

Divyanshu Garg (May 02 2026 at 07:32):

Divyanshu Garg (May 02 2026 at 07:36):

Kanchan Borole (May 02 2026 at 07:39):

Divyanshu Garg (May 02 2026 at 07:51):

Kanchan Borole (May 03 2026 at 05:01):

Divyanshu Garg (May 03 2026 at 07:30):

Divyanshu Garg (May 03 2026 at 07:51):

Kanchan Borole (May 03 2026 at 15:08):

Daniel Rossberg (May 03 2026 at 16:20):

Kanchan Borole (May 04 2026 at 08:52):

Divyanshu Garg (May 04 2026 at 16:36):

Himanshu (May 04 2026 at 19:25):

Kanchan Borole (May 05 2026 at 09:08):

Kanchan Borole (May 05 2026 at 09:08):

Divyanshu Garg (May 05 2026 at 09:30):

Divyanshu Garg (May 05 2026 at 09:30):

Daniel Rossberg (May 05 2026 at 10:33):

Kanchan Borole (May 05 2026 at 13:58):

Sean (May 05 2026 at 16:50):

Kanchan Borole (May 06 2026 at 09:55):

Divyanshu Garg (May 06 2026 at 09:56):

Kanchan Borole (May 06 2026 at 10:03):

Divyanshu Garg (May 06 2026 at 10:09):

Kanchan Borole (May 06 2026 at 10:24):

Daniel Rossberg (May 06 2026 at 10:31):

Kanchan Borole (May 06 2026 at 10:35):

Daniel Rossberg (May 06 2026 at 10:48):

Daniel Rossberg (May 06 2026 at 10:52):

starseeker (May 06 2026 at 11:29):

Daniel Rossberg (May 06 2026 at 12:12):

Divyanshu Garg (May 06 2026 at 15:28):

Daniel Rossberg (May 06 2026 at 19:20):

starseeker (May 07 2026 at 00:10):

Daniel Rossberg (May 07 2026 at 14:35):

Kanchan Borole (May 08 2026 at 12:09):

Divyanshu Garg (May 08 2026 at 12:12):

Kanchan Borole (May 08 2026 at 12:18):

Divyanshu Garg (May 08 2026 at 12:24):

Himanshu (May 09 2026 at 14:18):

Himanshu (May 09 2026 at 14:19):

starseeker (May 09 2026 at 19:25):

Kanchan Borole (May 11 2026 at 09:06):

Sean (May 12 2026 at 20:34):

Daniel Rossberg (May 13 2026 at 07:18):

Kanchan Borole (May 13 2026 at 12:10):

Daniel Rossberg (May 14 2026 at 13:47):

Sean (May 14 2026 at 20:29):

Kanchan Borole (May 17 2026 at 09:12):

Sean (May 18 2026 at 15:08):

Kanchan Borole (May 20 2026 at 11:22):

Kanchan Borole (May 24 2026 at 10:53):

Divyanshu Garg (May 24 2026 at 11:10):

Kanchan Borole (May 24 2026 at 11:39):

Divyanshu Garg (May 24 2026 at 11:40):

Kanchan Borole (May 25 2026 at 05:27):

Himanshu (May 25 2026 at 17:40):

Himanshu (May 25 2026 at 17:42):

Kanchan Borole (May 26 2026 at 06:03):

Kanchan Borole (May 28 2026 at 05:11):

Divyanshu Garg (May 28 2026 at 15:08):

Kanchan Borole (May 28 2026 at 15:27):

Himanshu (May 29 2026 at 12:46):

Himanshu (May 31 2026 at 07:33):

Himanshu (May 31 2026 at 07:34):

Himanshu (May 31 2026 at 07:35):

Kanchan Borole (May 31 2026 at 08:28):

Himanshu (May 31 2026 at 21:02):

Himanshu (May 31 2026 at 21:05):