Use sys.executable for Python commands and add LLM config options

[DomPTech]

LLM Device:

• Expanded the LLM device properties to include more detailed configuration options (such as chat_model_name, api_key, api_base)
• Better/more docs
• Ollama server check also automatically pulls the required model if it's not download, controlled by the new auto_pull_model property

Startup Scripts:

• Updated the sample config file to use the new ollama_model property
• LLMConfig class matches the new properties
• Changed run_server and run_llm scripts to use sys.executable instead of uv. Originally we would call uv run python -m <detector_process>, which would first create a uv process, and then that process would create the underlying python process. However due to the volatility of process tracking/killing, the python process could become detached from the parent uv process, or killing the uv process might not properly terminate its children. Using sys.executable instead (which was already done in the DATA device for the tiled command) means that ProcessManager tracks the actual python process itself, instead of indirectly through uv.

[utkarshp1161]

Just reading the notebook :
I wonder if below means the agent was not able to call the right tools and then failed? Will increasing Recursion limit help?

prompt = "Get a scanned haadf image. Then get an EDS spectrum."
response = llm.query(prompt)
print(response)

Recursion limit of 5 reached without hitting a stop condition. You can increase the limit by setting the recursion_limit config key.
For troubleshooting, visit: https://docs.langchain.com/oss/python/langgraph/errors/GRAPH_RECURSION_LIMIT

[DomPTech]

This was a very interesting thing during testing actually. Basically what happened was the agent successfully acquired the image, and then tried to acquire an EDS spectrum. However, for some reason the acquire_spectrum tool on the DigitalTwin always seems to fail with a Tango error (according to the stack trace because the EDS device is not properly initialized). Thus it continued to try different things to no avail, even though it technically was correct. Perhaps we should raise an issue for this.

[utkarshp1161]

Interesting. A issue on this would be nice.

[utkarshp1161]

I wonder why ollama is treated here as a special case? just because it is offline?

[DomPTech]

Correct (this is the provider we tend to use the most often), so I added special functionality for auto starting ollama servers, pulling models, etc. But your comment actually did make me realize we don't need a device_property of ollama_model (since you can just do provider of ollama and chat_model_name of "gemma4:31b" example).

[utkarshp1161]

If chat chat_model_name has default value gpt-4o the api_base should be https://api.openai.com/v1?

[DomPTech]

init_chat_model doesn't require an api_base for most providers (for example if you wanted to use openai you just set the provider to openai and the model name to gpt-4o and it automatically handles the routing).

[utkarshp1161]

I would give a sort of warning message to the user with list of models already there to choose from. More like: print("this model_x is not available, these models are available .....model_a, model_b..., either choose from these or Proceed as is to pull the model_x which may take some time")

[DomPTech]

Good thought!