Skip to content

DOC: Iterate on documentation. - #275

Open
perolavsvendsen wants to merge 4 commits into
mainfrom
crazy-horse
Open

DOC: Iterate on documentation.#275
perolavsvendsen wants to merge 4 commits into
mainfrom
crazy-horse

Conversation

@perolavsvendsen

@perolavsvendsen perolavsvendsen commented Jun 16, 2026

Copy link
Copy Markdown
Member

A few iterations on the documentation. Highlights:

  • Reduced references to other applications, and included information about the RMS trademark
  • Clarified that stratigraphy is mapped to the stratigraphic column (which is stored in SMDA), not to SMDA (which is the database)
  • Minor linguistic improvements (?) here and there.
    • "SUMO" --> "Sumo"

Checklist

  • Tests added (if not, comment why) (N/A)
  • Test coverage equal or up from main (run pytest with --cov=src/ --cov-report term-missing)
  • If not squash merging, every commit passes tests
  • Appropriate commit prefix and precise commit message used
  • All debug prints and unnecessary comments removed
  • Docstrings are correct and updated
  • Documentation is updated, if necessary
  • Latest main rebased/merged into branch
  • Added comments on this PR where appropriate to help reviewers
  • Moved issue status on project board
  • Checked the boxes in this checklist ✅


You have now initialized FMU Settings.

>##### Important:

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replaced with build-in notification

Comment thread docs/src/overview.md Outdated
## Why FMU Settings?

Today, configuring your FMU project and connecting the data produced by FMU to the official masterdata in SMDA, is done by manually editing the global configuration yaml file. This can be a tedious and error-prone process.
For FMU results to be usable by other applications, they need to be referenced to master data - unique and shared definitions. Configuring these references by manually editing config files can be a tedious and error-prone process. Especially the mapping of stratigraphic data to official definitions in the stratigraphic column has a high risk of typos, and quality checking and validation is difficult.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a bit of info on why master data matters

Comment thread docs/src/index.md
- <a href="https://equinor.enterprise.slack.com/archives/C09MFKN4NC9" target="_blank" rel="noopener noreferrer">#fmu-settings slack channel</a>
- <a href="https://fmu.equinor.com" target="_blank" rel="noopener noreferrer">FMU portal</a>

### Upcoming features

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed this as it felt a bit misplaced in the documentation (?)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not so sure about this. The intention is to make users aware of upcoming features in FMU Settings when they first started using the app. Some of the user feedbacks are asking about new features like mapping to other FMU components. With this section the users are aware that we are working on that. It's debatable to put this in the documentation, but maybe this is the easiest place to put.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question is, I guess, if documentation should include only what is, not what will be. There is also a risk that the documentation makes promises to users that we won't keep, if other things are prioritized etc. Anyways, this is not particularly critical - I can put it back in 👍

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's fair point, documentation should only include the current state. I'm fine with removing this from docs if others agreed.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is ok to remove it. If we see that many users are coming to us with suggestions for new features or asking what will be added next we can consider to add it back in. For now I think it is better to remove it to avoid user expectation for new features, which, as Per Olav says, we sometimes can't keep


If an RMS zone or horizon does not exist in SMDA, select “Zone does not exist in SMDA”.

#### Upcoming feature: Automatic mapping

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed this as it felt a bit misplaced in the documentation (?)

fmu settings
```

NB: FMU Settings can be opened from anywhere in your project folder hierarchy by running the command `fmu settings`. FMU Settings will in that case automatically detect the nearest project. Inside the FMU Settings GUI you will be able to open a project either from the list of **recent projects** or by entering the project path manually.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to native tip box

@krhart

krhart commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

I'm not sure I agree with the SMDA vs stratigraphic column issue. In my head, stratigraphic column is very generic and just a schema/diagram that you use to sort the order of the stratigraphic elements. So RMS have it, OW have it, SMDA have it, etc. But maybe "official stratigraphic column" could work? On the other hand, I think it would be good that the users are familiar with SMDA anyway, and that SMDA is the official source of metadata. So if they don't know before, they will know after using FMU Settings.

@perolavsvendsen

Copy link
Copy Markdown
Member Author

I'm not sure I agree with the SMDA vs stratigraphic column issue. (...)

Yes, good points. And in hindsight, this part should probably have been a separate issue -> PR. Got carried away in editing mode... Have clarified it a bit more now. If more discussion is needed, I can reduce this PR to the "obvious" things only.

Comment thread docs/src/gui_user_guide.md Outdated
Comment thread docs/src/gui_user_guide.md Outdated
Comment thread docs/src/index.md
- <a href="https://equinor.enterprise.slack.com/archives/C09MFKN4NC9" target="_blank" rel="noopener noreferrer">#fmu-settings slack channel</a>
- <a href="https://fmu.equinor.com" target="_blank" rel="noopener noreferrer">FMU portal</a>

### Upcoming features

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not so sure about this. The intention is to make users aware of upcoming features in FMU Settings when they first started using the app. Some of the user feedbacks are asking about new features like mapping to other FMU components. With this section the users are aware that we are working on that. It's debatable to put this in the documentation, but maybe this is the easiest place to put.

perolavsvendsen and others added 2 commits June 17, 2026 14:55
Co-authored-by: Gibran Alfarizi <52709954+GibranAlfa@users.noreply.github.com>
@perolavsvendsen

Copy link
Copy Markdown
Member Author

As more discussion is possibly required on this PR, I suggest this be merged as a first step.

@slangeveld slangeveld left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Except from this SMDA vs stratigraphic column discussion we need to agree on, the rest looks good from my point of view.

@tnatt What is your take on this?

Comment thread docs/src/index.md
- <a href="https://equinor.enterprise.slack.com/archives/C09MFKN4NC9" target="_blank" rel="noopener noreferrer">#fmu-settings slack channel</a>
- <a href="https://fmu.equinor.com" target="_blank" rel="noopener noreferrer">FMU portal</a>

### Upcoming features

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is ok to remove it. If we see that many users are coming to us with suggestions for new features or asking what will be added next we can consider to add it back in. For now I think it is better to remove it to avoid user expectation for new features, which, as Per Olav says, we sometimes can't keep

@tnatt tnatt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should decide on whether we use SMDA stratigraphic column or stratigraphic column in SMDA, other than that these updates LGTM 🙂

If the project contains horizons or zones that no longer exist in RMS, FMU Settings asks you to remove them before saving.

## Step 5: Map RMS stratigraphy to SMDA
## Step 5: Map RMS stratigraphy to the SMDA stratigraphic column

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what is the most correct, but I would write this as

Suggested change
## Step 5: Map RMS stratigraphy to the SMDA stratigraphic column
## Step 5: Map RMS stratigraphy to the stratigraphic column in SMDA

I see we sometimes write it like this, but most places we say SMDA stratigraphic column. We should try to be consistent here.

Comment thread docs/src/index.md
# FMU Settings documentation

**FMU Settings** is a tool that will simplify the handling of FMU model metadata, meaning metadata related to the FMU model itself and metadata needed when you are exporting data objects from FMU models.
**FMU Settings** is a tool that will simplify the handling of FMU model metadata (metadata related to the FMU model itself) and references to master data (required for making FMU results usable in other applications and contexts).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence is a bit heavy, maybe we can try to shorten it a bit.. do we need the first parentheses here?

Suggested change
**FMU Settings** is a tool that will simplify the handling of FMU model metadata (metadata related to the FMU model itself) and references to master data (required for making FMU results usable in other applications and contexts).
**FMU Settings** is a tool that simplifies the handling of FMU model metadata and references to master data (required for making FMU results usable in other applications and contexts).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants