Skip to main content

I am trying to write a custom GRIN *.dll file for non sequential mode that will allow me to limit refractive index above or below a certain value and just set it to a constant. However, I am having a hard time defining the derivatives to return as required in the GRIN *.dll files. As an example, if my refractive index looks something like below:

 

I would like to cut everything off above and below a certain threshold, even if my n(x,y,z) function gives me a value thats within it. I have currently been doing this with just a merit function and limiting index that way, but would like to be able to just programmatically restrict it.

 

I also tried a variant where I set the derivatives to 0 or ignored them, but had errors tracing the rays.

 

Anyone have a good solution? Happy to provide any files needed.

@mlunin,

 

Since you didn’t provide any code, I’m assuming you are already familiar with writing DLLs and you are asking on a conceptual level (correct me if I’m wrong). You can have two parameters in your DLL a minimum_index and a maximum_index. Then, when you calculate your n(x, y, z) in the DLL, you check if the value is within the boundaries defined above. If it is, you keep it as such, otherwise you replace it with minimum_index or maximum_index accordingly. In pseudo-code you will do the following.

UserParamNames

if (i == XX) strcpy(data, "Minimum index");
if (i == XX+1) strcpy(data, "Maximum index");

UserGrinDefinition

minimum_index = data 10+XX]
maximum_index = data 11+XX]

index = n(x, y, z) # As defined by yourself

if index < minimum_index
index = minimum_index
elif index > maximum_index
index = maximum_index

XX is an integer parameter number as defined in other Grin DLLs.

The derivatives are zero where the refractive index is constant. Mathematically speaking there’s a discontinuity in the bounded function and the derivative isn’t defined at the bounds, but programmatically you can choose to either use zero or the derivative of n(x, y, z) at that position if it hadn’t been bounded (or something else). Note that I didn’t try myself, and if that’s already what you are doing, can you give us more detail as to why it doesn’t work?

Take care,

 

David


I have tried this, and it does work with (some) success. The main problem I have is when the index DOES go back to being valid, the program does not recognize that index change, and the ray continues to behave as if it hit max_index or min_index. I have analyzed a single ray trace, and noticed this behavior. It also seems to throw a bunch of geometry errors eventually. 

I need an effective way of how to handle changes BACK to a new refractive index. It might require storing the previous values, but I’ve had a hard time with that. The step sizes are inconsistent and random sometimes. There’s also no great way to handle storing it. The main two ways I’ve thought of is writing directly to a *.txt and recalling from there (slow) or using the data array, say at spot 200 or something. However, the data array seems to sometimes overwrite what you store.

I am actively working on this, so this is all WIP.


@mlunin,

 

Apologies, but I don’t quite get the problem. Can you tell me more about why you want to store previous value of the refractive index? As far as I know, for any ray, the index is calculated at every (x, y, z) step and there’s no randomness in the size of the steps. Would you mind sharing your code with us along with a sample file that demonstrate the issue?

Take care,

 

David


Reply