Divyanshu Garg (May 01 2026 at 08:20): Divyanshu Garg (May 01 2026 at 08:20):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):On that note, Welcome to the chat!
Kanchan Borole (May 01 2026 at 08:42):Thank you @Divyanshu Garg. Looking forward to getting started!
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:-
Once this is all done, we will potentially be ready for the coding period.
Divyanshu Garg (May 01 2026 at 09:33):Another important aspect of contribution would be communication,
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):Hey @Kanchan Borole
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):https://github.com/BRL-CAD/arbalest/blob/main/README.md
This file mentions that
Divyanshu Garg (May 02 2026 at 07:36):Have you already setup BRL-CAD core on your system?
Kanchan Borole (May 02 2026 at 07:39):I have Installed BRL-CAD(7.32.2) not build it from source.
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):Hi @Kanchan Borole have you tried setting this https://github.com/BRL-CAD/MOOSE?
Divyanshu Garg (May 03 2026 at 07:51):https://github.com/BRL-CAD/arbalest/blob/main/README.md Please check this out
BRL-CAD/core wont include it by default
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.
In addition, I wrote down the general process of building arbalest from source here: https://drossberg.github.io/BRL-CAD/compiling.html
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):Hey @Kanchan Borole any luck getting it up and running?
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):Welcome to the project @Himanshu
Happy to have you here
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):Thanks @Daniel Rossberg , I’ll update the configuration accordingly.
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):Missing methods mostly indicate a version mismatch issue :thinking:
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:
I keep testing arbalest.
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 Do you use AI for development?
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):Anyone faced this issue?
Himanshu (May 09 2026 at 14:19):Is that possible to skip or is it necessary?
starseeker (May 09 2026 at 19:25):Whoops. I think I fixed it in latest main - shouldn't be needed anymore.
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:
In addition, putting the V&V stuff in a subfolder sounds reasonable.
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.
Some small Arbalest-side GUI integration changes were needed so far mainly in:
MainWindow.cpp
I also added VV-related files such as:
VVWidget.h / VVWidget.cpp
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):Official repostory works, since the code is gonna be merged there evetually
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):Kanchan Borole said:
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 undersrc/plugins/vv/ui/(VVWidget,VVDockWidget,VVIssueDialog,VVTestSelectionDialog), updated the relevantCMakeLists.txt, and integrated them throughMainWindow.In
MainWindow.hI addedvvDockable,vvWidget,vvTimer,vvValidationQueue,vvRunning,vvCurrentIndex,vvTests,vvSuites, and the methodsstartVVValidation(),processVVValidation(), andstopVVValidation().In
MainWindow.cppI 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 inprepareDockables(), 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, issrc/plugins/vv/the appropriate location for this functionality, or would you recommend a different folder structure?
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):Tbh it will be easy if you push that PR. :wink:
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.
Last updated: May 27 2026 at 02:30 UTC