Migrate solver execution logging in DataFileClass.run() from print() to logging

[parthdagia05]

Refactor: Migrate Solver Execution Logging to Python logging 🪵

Closes: #14

Overview

This PR replaces legacy print() statements within the DataFileClass.run() method with Python’s native logging module.

As the project evolves toward cross-platform support and more complex solver workflows, transitioning from unformatted stdout to structured logging is essential for professional debugging, maintainability, and future-proofing.

---

Changes

1. Structured Logging in DataFileClass

• Informational Logs: Replaced timing and progress print() calls with logger.info().
• Enhanced Error Handling: Replaced standard print(ex) with logger.error(..., exc_info=True). This captures the full stack trace in the server logs while maintaining a clean output for the end-user.
• Contextual Metadata: Console logs now automatically include:
  • ISO-8601 Timestamps
  • Module/Logger Name (DataFileClass)
  • Log Severity Level (INFO, ERROR, etc.)

2. Centralized Configuration

Introduced a standardized logging configuration in API/app.py:

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s [%(name)s] %(levelname)s: %(message)s"
)

---

[parthdagia05]

@VedranKapor can you review this

[Aaravanand00]

Hi @parthdagia05 Great refactor — this definitely improves maintainability and makes the solver pipeline more production-ready. Moving away from print() is an important step, especially as MUIO evolves toward cross-platform support and potentially more complex or coupled solver workflows.

One small suggestion: it might be beneficial to explicitly use logging.getLogger(__name__) within the class rather than relying solely on basicConfig. This would make the logging setup more modular and resilient in environments where logging may already be configured (e.g., under a WSGI server or future deployment scenarios).

Additionally, introducing some DEBUG-level logs for fine-grained stage timing (while keeping high-level milestones at INFO) could make the logging more flexible for profiling and performance diagnostics without increasing default verbosity.

Overall, this is a clean and low-risk improvement — nice work

[parthdagia05]

Hi @Aaravanand00,

Thank you for the thoughtful feedback.

I’ve incorporated the refinements directly into the existing commit:
Ensured the class uses logging.getLogger(name) for modular logger usage.
Added DEBUG-level logs for finer-grained solver stage execution while keeping milestone events at INFO.
Guarded logging.basicConfig to avoid overriding existing handlers in deployment environments.

[VedranKapor]

Just wanted to say thanks for forking repo and adding the logger. I’m currently working on a real‑time logging system for the optimization runs, since they can take a while and it’s useful for users to see live progress.
Just wanted to let you know and say thanks for taking the time to contribute. Feel free to jump in with ideas anytime — always appreciated!

[parthdagia05]

Hi @VedranKapor,

A real-time logging system for optimization runs sounds very valuable, especially for longer executions where user feedback makes a big difference in perceived responsiveness.

I’d definitely be interested in contributing if there’s anything I can help with whether it’s structuring the logging flow, exploring streaming updates (e.g., via websockets), or helping design a clean interface between the solver and the frontend.

Looking forward to collaborating further!