[gearboy]

Debugging Fluent UDF is always the pain point for users. Intermediate variables can't be inspected and the source can't be traced step by step. User's progress remains stagnant especially because of inexplicable errors. Here, we recommend a UDF debugging tool that can directly inspect intermediate variables and trace the UDF source step by step.

https://vcudfstudio.bitbucket.io/dow...uent%20UDF.pdf

[eeroi]

Originally Posted by gearboy

Debugging Fluent UDF is always the pain point for users. Intermediate variables can't be inspected and the source can't be traced step by step. User's progress remains stagnant especially because of inexplicable errors. Here, we recommend a UDF debugging tool that can directly inspect intermediate variables and trace the UDF source step by step.

https://vcudfstudio.bitbucket.io/dow...uent%20UDF.pdf

The simplest way? Really? How much is it then? I am sick of these marketing gimmicks.

For those of you who would prefer not to pay for shady additional software and would like to keep information free, I am proposing the following following GENUINELY-FREE-OF-CHARGE approach, which I find even simpler than your FREE-TO-TRY slash GIVE-ME-YOUR-MONEY solution:

- Remember to back original files up before you make any changes.

- Change the makefile template makefile_nt.udf (in one of the Fluent installation folders):

CFLAGS = /c /Za /Zi /DUDF_EXPORTING /DUDF_NT /DWIN64 /EHa /wd4224

link $(LIBS) /dll /debug /assemblydebug /out:$(TARGET)

In words, you add the compiler flag /Zi and linker flags /debug /assemblydebug, nothing else. These options generate the program database (.pdb) files that you'll later find in the binary output folders.

- Compile the UDF code in Fluent GUI and load the libudf library. This seems to be the best (most stable and universal) approach for compilation these days, earlier you had to run nmake in command prompt.

- Open the source file in the "libudf/src" folder in Visual Studio (a free Express version will do fine).

- In Visual Studio, attach the code to fl_mpi1950.exe (Fluent 2019R3). This works in serial mode, in parallel you may have to attach to all Fluent processes (haven't used in years, don't remember anymore). You should see debug symbols loaded in VS.

- Try adding a breakpoint on a code row. The red circle on the left hand side should be filled, if the attach was successful.

- When you run the simulation, whenever the code with the breakpoint is called within Fluent, you should now break in Visual Studio and be able to see the variable content and track program flow. Please see https://ibb.co/K2pPh6K for a screenshot.

No need to extend your wallet.



Cheers, Eero

[gearboy]

Please do not disparage a car just because you have a pair of muscular legs. Not everyone master or prefer "Marathon" like you. Quite a few people enjoy the convenience even if cars "extend their wallet".

Originally Posted by eeroi

The simplest way? Really? How much is it then? I am sick of these marketing gimmicks.

For those of you who would prefer not to pay for shady additional software and would like to keep information free, I am proposing the following following GENUINELY-FREE-OF-CHARGE approach, which I find even simpler than your FREE-TO-TRY slash GIVE-ME-YOUR-MONEY solution:

- Remember to back original files up before you make any changes.

- Change the makefile template makefile_nt.udf (in one of the Fluent installation folders):

CFLAGS = /c /Za /Zi /DUDF_EXPORTING /DUDF_NT /DWIN64 /EHa /wd4224

link $(LIBS) /dll /debug /assemblydebug /out:$(TARGET)

In words, you add the compiler flag /Zi and linker flags /debug /assemblydebug, nothing else. These options generate the program database (.pdb) files that you'll later find in the binary output folders.

- Compile the UDF code in Fluent GUI and load the libudf library. This seems to be the best (most stable and universal) approach for compilation these days, earlier you had to run nmake in command prompt.

- Open the source file in the "libudf/src" folder in Visual Studio (a free Express version will do fine).

- In Visual Studio, attach the code to fl_mpi1950.exe (Fluent 2019R3). This works in serial mode, in parallel you may have to attach to all Fluent processes (haven't used in years, don't remember anymore). You should see debug symbols loaded in VS.

- Try adding a breakpoint on a code row. The red circle on the left hand side should be filled, if the attach was successful.

- When you run the simulation, whenever the code with the breakpoint is called within Fluent, you should now break in Visual Studio and be able to see the variable content and track program flow. Please see https://ibb.co/K2pPh6K for a screenshot.

No need to extend your wallet.



Cheers, Eero

[eeroi]

Originally Posted by gearboy

Please do not disparage a car just because you have a pair of muscular legs. Not everyone master or prefer "Marathon" like you. Quite a few people enjoy the convenience even if cars "extend their wallet".

Marathon? You do not want to engage in this discussion. The procedure I described takes me 20 seconds to complete. A first-timer might spend 5 minutes on it, searching for the right files, compile/load/attach buttons in Fluent and Visual Studio. How is that for simplicity? Installing your software and following the pdf instructions takes more time.

What really bothers me is that you pretend to be helpful while promoting your commercial stuff. Nothing wrong with being a vendor, but you should say it openly.

Forum rules (I quote):

State your affiliation explicitly in your message if you:
Recommend a product sold by your employer.
Write bad things about a product and you are employed by a company selling similar products.

Forbidden content:
Advertising, both commercial and personal

[gearboy]

Originally Posted by eeroi

Marathon? You do not want to engage in this discussion. The procedure I described takes me 20 seconds to complete. A first-timer might spend 5 minutes on it, searching for the right files, compile/load/attach buttons in Fluent and Visual Studio. How is that for simplicity? Installing your software and following the pdf instructions takes more time.

What really bothers me is that you pretend to be helpful while promoting your commercial stuff. Nothing wrong with being a vendor, but you should say it openly.

Forum rules (I quote):

State your affiliation explicitly in your message if you:
Recommend a product sold by your employer.
Write bad things about a product and you are employed by a company selling similar products.

Forbidden content:
Advertising, both commercial and personal

That's our fault. Sorry. We should show this is an advertisement in the title. Whether it is helpful or not depends on users. Sorry to make you angry.

[eeroi]

Originally Posted by gearboy

That's our fault. Sorry. We should show this is an advertisement in the title. Whether it is helpful or not depends on users. Sorry to make you angry.

Why not edit the initial post to clearly state your commercial aims then?

[gearboy]

Originally Posted by eeroi

Why not edit the initial post to clearly state your commercial aims then?

The forum doesn't allow editing or deleting for topic with a long histroy, only allowing reply. It was posted long time ago.

[rodolfolondero]

Hello, could you provide the screenshots of the step-by-step procedure, please?

Originally Posted by eeroi

The simplest way? Really? How much is it then? I am sick of these marketing gimmicks.

For those of you who would prefer not to pay for shady additional software and would like to keep information free, I am proposing the following following GENUINELY-FREE-OF-CHARGE approach, which I find even simpler than your FREE-TO-TRY slash GIVE-ME-YOUR-MONEY solution:

- Remember to back original files up before you make any changes.

- Change the makefile template makefile_nt.udf (in one of the Fluent installation folders):

CFLAGS = /c /Za /Zi /DUDF_EXPORTING /DUDF_NT /DWIN64 /EHa /wd4224

link $(LIBS) /dll /debug /assemblydebug /out:$(TARGET)

In words, you add the compiler flag /Zi and linker flags /debug /assemblydebug, nothing else. These options generate the program database (.pdb) files that you'll later find in the binary output folders.

- Compile the UDF code in Fluent GUI and load the libudf library. This seems to be the best (most stable and universal) approach for compilation these days, earlier you had to run nmake in command prompt.

- Open the source file in the "libudf/src" folder in Visual Studio (a free Express version will do fine).

- In Visual Studio, attach the code to fl_mpi1950.exe (Fluent 2019R3). This works in serial mode, in parallel you may have to attach to all Fluent processes (haven't used in years, don't remember anymore). You should see debug symbols loaded in VS.

- Try adding a breakpoint on a code row. The red circle on the left hand side should be filled, if the attach was successful.

- When you run the simulation, whenever the code with the breakpoint is called within Fluent, you should now break in Visual Studio and be able to see the variable content and track program flow. Please see https://ibb.co/K2pPh6K for a screenshot.

No need to extend your wallet.



Cheers, Eero